먼저 TDD를 수행할 때, 정확히는 어떤 서비스를 개발할 때 우리가 무엇을 개발할 것인지 분석해야한다. 쉽게 설명하면, 건물을 지을때 도 설계도를 먼저 만든 뒤 이를 기반으로 건물을 짓는다.
마찬가지로 소프트웨어 또한 개발할 때, 무작정 코드를 작성하기 시작할 것이 아니라 필요한 기능들을 정의한, 내가 만들고자 하는 서비스는 어떤 기능을 제공하는지 그리고 각 기능을 제공하기 위해 무엇이 필요한지 분석하고, 이를 바탕으로 소프트웨어를 개발해 나가기 시작해야 한다.
본 글은 TDD와 관련된 글이기 때문에, 분석이 어떻게 진행되는지와 관련해서 자세히 설명하지 않겠다. 나중에 필요할 경우 해당 글을 연재하겠다. 쉽게 소프트웨어개발방법론 이라고 불리는데, 우리가 흔히 아는 Waterfall, Agile, Unified Process 등이 그 예시이다.
TDD는 간단히 말해 이렇게 우리가 분석한 요구사항, Requirements들에 대해 어떻게 되어야 기능 개발에 성공한것인지, 어떤 실패 케이스가 있는지 찾고 실제로 코드를 실행하여 내가 분석한 Requirements, 즉 해당 기능이 잘 동작하는지 확인하는 것이다.
우리는 User 정보를 관리하는 API를 만들것인데, 간단히 CRUD 위주의 기능을 분석, 설계하고 개발하겠다.
CRUD를 위주로, 우리는 4개의 Primary Requirements를 찾을 수 있다. 만약 RESTful API에 대해 잘 모른다면, 아래 글을 참고하자.
Create: 새로운 User를 만들 수 있어야 한다. Read: 기존의 User 정보를 읽을 수 있어야 한다. Update: 기존의 User를 갱신할 수 있어야 한다. Delete: 기존의 User를 삭제할 수 있어야 한다.
RESTful API를 설계할 것이기 때문에, 각 CRUD에 대응하는 HTTP Request 및 간략한 요구사항 분석은 다음과 같다.
Create
POST /user
새로운 User를 생성한다. 이 때 Body Parameter를 통해 새로운 User를 생성하는데 필요한 정보를 전달받는다.
만약, 생성에 성공했을 경우 HTTP 201 Created를 반환한다.
만약, 생성 요청된 email을 가지는 User가 이미 존재할 경우 HTTP 409 Conflict를 반환한다.
Read
GET /user/email/{email}
기존의 User 정보를 읽어온다. 이 때 특정 User를 구분하기 위해서는 email을 전달받고, 해당 User를 찾아 return한다. 이 때 HTTP 응답 코드는 HTTP 200 Ok를 반환한다.
만약, User가 존재하지 않을 경우 HTTP 204 Empty를 반환한다.
Update
PUT /user/email/{email}
기존의 User 정보를 갱신한다. 이 때 User를 특정하기 위해 email을 구분자로 사용한다.
만약, 해당하는 email을 가진 User가 없을 경우 HTTP 400 Bad Request를 응답한다.
PUT Method이지만, 새로운 Content를 생성하는 경우는 없다.
DELETE
DELETE /user
기존의 User를 삭제한다. 이 때 User를 특정하기 위해 email을 Body Parameter로 전달받는다.
User 삭제에 성공한 경우, HTTP 200 OK와 함께 삭제된 유저의 수를 반환한다.
만약 해당하는 User가 없을 경우 HTTP 204 No Content를 반환한다.
위를 살펴보면, 우리는 성공여부와 실패여부를 미리 가정했다. 뿐만 아니라, 어떤 역할을 해야하는지 Informal한 형태로 분석했다. 이를 통해 우리는 CRUD를 구현할 때, 해당 기능이 어떤것을 수행하는지 미리 알 수 있다. 더 나아가 구현하지 않았음에도, 어떤 응답을 받을지 이미 알고있다.
이를 쉽게 말하면, 우리는 Test Case를 구현하기 위해 어떤 행동들을 해야 하는지 벌써 알고있다.
이제 실제 구현을 위해 코드를 작성해보자. 시스템 구현을 위한 외부 소프트웨어는 다음과 같다.
MongoDB, Mongoose
MongoDB: User 정보를 저장하는데 사용될 Database
Mongoose: MongoDB를 위한 TypeODM Library.
Redis
MongoDB에서 가져온 Data를 캐싱하는데 사용할 Memory Database
사실 Redis는 굳이 사용하지 않아도 상관없지만, 요즘은 Redis를 사용하는 것이 추세이기 때문에, 작성하였다.
우리 시스템의 생김새는 다음과 같다.
Repository도 사용할까 했는데, TDD가 주 목적이기 때문에 제외하였다. Controller를 통해 user에 대한 요청이 발생하면, Service를 통해 Model로 부터 데이터를 생성,반환,갱신,삭제 를 수행한다. 이 때 Redis를 이용해 만약 데이터가 캐싱되어 있을 경우, 해당 데이터를 반환한다.
이전 글에서도 말했지만, 우리는 Test를 다음과 같이 수행할 예정이다.
Unit Test
Service가 Model로부터 데이터를 잘 가져오는지 테스트
즉 Service를 테스트하기 위한 Controller 테스트 코드 작성 Integration Test
Unit Test를 진행할 때, 현재 테스트 할 기능 단위에 필요한, 의존성을 갖는 기능들은 모두 잘 동작한다고 가정하고 테스트를 진행한다. 그래서 실제로는 User의 코드와 User에서 사용할 Redis의 코드는 별개로, Redis는 주어진 Interface대로 잘 동작할 것이다. 고 가정한다. 하지만 우리는 아직 Unit Test를 위해 이러한 가정을 어떻게 만드는지 모르기 때문에, Redis를 통해 먼저 Mock Data (Object)를 만드는 것을 연습한 뒤, User를 통해 실제 Unit Test를 진행하겠다. 즉 오늘은 Redis를 통해 Mock과 친해지고, 다음 글에서 본격적인(사실 이번 글도 본격적인 TDD다.) TDD를 진행하겠다.
Redis의 사용 목적은 Data Caching을 통해 Server 및 DB의 부하를 줄이는 것이다. 즉, 다음과 같은 기능을 수행할 수 있어야 한다.
Set Cache: DB로 부터 가져온 데이터를 캐싱할 수 있어야 한다. Get Cache: 저장된 캐시를 반환할 수 있어야 한다. Delete Cache: 저장된 캐시를 삭제할 수 있어야 한다. Reset Cache: 현재 저장된 모든 캐시를 초기화할 수 있어야 한다.
import { CacheModule, Module } from '@nestjs/common';
import { RedisManagerService } from './redis-manager.service';
import * as redisStore from 'cache-manager-ioredis';
@Module({
imports: [
CacheModule.register({
store: redisStore,
host: 'localhost',
port: 6399,
ttl: 0,
}),
],
providers: [RedisManagerService],
exports: [RedisManagerService],
})
export class RedisManagerModule {}
redis-manager.service.ts
import { CACHE_MANAGER, Inject, Injectable } from '@nestjs/common';
import { Cache } from 'cache-manager';
import { User } from '../user/data/user.schema';
@Injectable()
export class RedisManagerService {
constructor(
@Inject(CACHE_MANAGER)
private readonly cacheManager: Cache,
) {}
/**
* Set the object in Redis
* @param key Key to identify the object
* @param value User to set for the key
* @returns true when succeeded
*/
async setCache(key: string, value: User): Promise<boolean> {
await this.cacheManager.set(key, value);
return true;
}
/**
* Return the object that matches key in Redis
* @param key Key to identify the object
* @returns User when the item exist in Redis
* @returns undefined when the item is not exist in Redis
*/
async getCache(key: string): Promise<User> {
const result = await this.cacheManager.get(key);
if (!result) {
return null;
}
return result as User;
}
/**
* Delete the object that matches key in Redis
* @param key Key to delete from Redis
* @returns true when succeeded
*/
async deleteCache(key: string): Promise<boolean> {
await this.cacheManager.del(key);
return true;
}
/**
* Reset all the data stored in Redis
* @returns true when succeeded
*/
async resetCache(): Promise<boolean> {
await this.cacheManager.reset();
return true;
}
}
주석을 달아놓았기 때문에 코드를 읽는데 문제 없을것이라 생각한다.
이제 Redis에 대한 Unit Test를 진행해보자. 이 때 먼저 고려해야할 것은 Redis를 사용하기 위한 의존 기능은 무엇이 있는가?이다. 이것을 찾지 못한다면 Redis에 대한 TDD를 수행하기 어렵다.
NestJS는 고맙게도 해당 모듈이 어떤 의존성을 가지는지 우리는 쉽게, 정확히는 이미 알고있다.
먼저 redis-manager.module.ts 를 통해 우리의 Redis 모듈이 외부의 어떤 기능을 제공받는지 확인할 수 있다.
Redis Service는 cacheManager 라는 것을 의존성으로 갖는데, 이는 CACHE_MANAGER로, 다음의 역할을 수행한다.
cacheManager.set: Redis에 캐시를 저장한다. cacheManager.get: Redis로 부터 캐시를 획득한다. cacheManager.del: Redis로 부터 캐시를 삭제한다. cacheManager.reset: Redis의 캐시를 삭제한다.
즉, 해당 의존성을 통해 실제 레디스에 데이터를 저장하고 삭제한다.
위를 토대로 우리는 redis-manager.module.ts와 redis-manager.service.ts로 부터 다음 의존성을 찾을 수 있다.
Redis 연결을 수행하기 위한 CacheModule.register 동작이 필요하다.
Redis에 실제 데이터를 저장,삭제,획득,초기화 등을 수행하는 CACHE_MANAGER가 필요하다.
이제 진짜 Redis의 Test 코드를 작성해 보자. 지난 글을 바탕으로, 우리는 다음과 같은 초기 코드를 작성할 수 있다.
import { Test } from '@nestjs/testing';
import { RedisManagerService } from '../redis-manager.service';
describe('RedisManagerController', () => {
let service: RedisManagerService;
const key = 'file/yes-data';
beforeEach(async () => {
const moduleRef = await Test.createTestingModule({
providers: [],
}).compile();
service = moduleRef.get<RedisManagerService>(RedisManagerService);
});
});
하지만 위 코드대로 test를 수행한다면, 다음 에러가 발생할 것이다.
npm test redis-manager.controller 1 ✘ 23:44:22
> tdd@0.0.1 test
> jest "redis-manager.controller"
FAIL src/redis-manager/test/redis-manager.controller.spec.ts
RedisManagerController
✕ should be defined (5 ms)
● RedisManagerController › should be defined
**Nest can't resolve dependencies of the RedisManagerService (?). Please make sure that the argument CACHE_MANAGER at index [0] is available in the RootTestModule context.
Potential solutions:
- Is RootTestModule a valid NestJS module?
- If CACHE_MANAGER is a provider, is it part of the current RootTestModule?
- If CACHE_MANAGER is exported from a separate @Module, is that module imported within RootTestModule?
@Module({
*imports: [ /* the Module containing CACHE_MANAGER */ ]*
})**
7 |
8 | beforeEach(async () => {
> 9 | const moduleRef = await Test.createTestingModule({
| ^
10 | providers: [RedisManagerService],
11 | }).compile();
12 |
at TestingInjector.lookupComponentInParentModules (../node_modules/@nestjs/core/injector/injector.js:247:19)
at TestingInjector.resolveComponentInstance (../node_modules/@nestjs/core/injector/injector.js:200:33)
at TestingInjector.resolveComponentInstance (../node_modules/@nestjs/testing/testing-injector.js:19:45)
at resolveParam (../node_modules/@nestjs/core/injector/injector.js:120:38)
at async Promise.all (index 0)
at TestingInjector.resolveConstructorParams (../node_modules/@nestjs/core/injector/injector.js:135:27)
at TestingInjector.loadInstance (../node_modules/@nestjs/core/injector/injector.js:61:13)
at TestingInjector.loadProvider (../node_modules/@nestjs/core/injector/injector.js:88:9)
at ../node_modules/@nestjs/core/injector/instance-loader.js:49:13
at async Promise.all (index 3)
at TestingInstanceLoader.createInstancesOfProviders (../node_modules/@nestjs/core/injector/instance-loader.js:48:9)
at ../node_modules/@nestjs/core/injector/instance-loader.js:33:13
at async Promise.all (index 1)
at TestingInstanceLoader.createInstances (../node_modules/@nestjs/core/injector/instance-loader.js:32:9)
at TestingInstanceLoader.createInstancesOfDependencies (../node_modules/@nestjs/core/injector/instance-loader.js:21:9)
at TestingInstanceLoader.createInstancesOfDependencies (../node_modules/@nestjs/testing/testing-instance-loader.js:9:9)
at TestingModuleBuilder.createInstancesOfDependencies (../node_modules/@nestjs/testing/testing-module.builder.js:97:9)
at TestingModuleBuilder.compile (../node_modules/@nestjs/testing/testing-module.builder.js:63:9)
at Object.<anonymous> (redis-manager/test/redis-manager.controller.spec.ts:9:23)
Test Suites: 1 failed, 1 total
Tests: 1 failed, 1 total
Snapshots: 0 total
Time: 1.484 s, estimated 2 s
Ran all test suites matching /redis-manager.controller/i.
해당 오류를 자세히 보면, Redis Module은 CACHE_MANAGER를 의존성으로 갖는데, 찾을 수 없다는 내용이다.
Nest can't resolve dependencies of the RedisManagerService (?). Please make sure that the argument CACHE_MANAGER at index [0] is available in the RootTestModule context. … imports: [ / the Module containing CACHE_MANAGER / ] …
따라서, 우리는 CACHE_MANAGER에 대한 Mock 을 만들어줘야 한다.
다시 말하면, cache-manager, cache-manager-ioredis가 수행하는 Redis Software에 데이터를 저장하고, 읽고, 삭제하는 등의 Test Mockup을 만들어야 한다.
Mockup을 만들기 전에, 내가 사용하는 Test Directory 구조는 다음과 같다.
mocks
Mock과 관련된 자료형, 함수, 클래스 등을 저장할 폴더
test
실제 test 코드를 작성할 폴더
이외에도 다음이 있다.
data
해당 기능이 가지는 data(schema, repository, dto, … 등)을 저장하는 폴더
test/stubs
해당 기능을 테스트하는데 필요한 mock 객체를 저장할 폴더
본격 Mock 만들기 — User Mock Data
Mock 모조품, 가짜
Mock을 만드는 이유는 우리가 테스트할 기능에 필요한 외부 기능(의존성)이 마치 잘 동작하는것처럼 보여주기 위해 만드는 것이다. 다시 정리하자면, 우리 시스템의 Redis는 cache-manager-ioredis, cache-manager 라이브러리가 제공하는 실제 Redis 소프트웨어 연결 및 실제 데이터 작성, 읽기, 삭제 등이 잘 동작하는 것으로 가정해야 하기 때문이다. 우리는 Redis Manager Module을 작성함으로써 User Module(더 나아가 Redis를 이용하는 모든 모듈)에서 발생하는 이러한 캐싱 동작에 대해, Redis 소프트웨어와 실제 통신함으로써 그 동작이 수행되도록 하는 역할을 한다. 따라서, 실제 테스트 코드에서는 이러한 연결 및 Redis의 라이브러리에서 제공하는 기능(get, set, ...)은 100% 잘동작한다고 가정, 우리의 코드 setCache, getCache, ...를 테스트하기 위해 만드는 것이다. 즉, 이러한 가정을 제공하기 위한 Mock을 만드는 것이다.
우리는 먼저 Redis의 CACHE_MANAGER에 대한 Mock, 즉 진짜처럼 동작하는 가짜를 만들어야한다. 그런데 생각해보니 Redis는 Cache Manager를 통해 User를 캐싱하고, 획득하고, 삭제하는데 이때 User와 관련된 자료형이 필요하다.
따라서 우리는 Redis 기능을 만족시키기 위해 User의 Mock Data 또한 만들어줘야 한다.
사용할 User는 우리가 위에서 정의한 user.schema.ts의 모든 Property를 가져야 하고, 동시에 필요한 자료만 있으면 되기 때문에 다음과 같이 정의하겠다.
해당 파일은 user/test/stubs/user.stub.ts다.
import { User } from '../../../user/data/user.schema';
//* 아래의 속성들은 분명 user.schema.ts에 정의되어있다.
export const mockUserDto: any = {
id: 'test-id',
email: 'test@test.com',
nickname: 'test-nickname',
password: 'test-password',
};
//* mockUserStub을 통해 User 모조품을 반환한다.
export const mockUserStub = (): User => {
return mockUserDto;
};
우리는 mockUserDto를 통해 하나의 Dto(자료형)를 나타낼 것이고, mockUserStub을 통해 실제 User가 반환되는 결과를 나타낼 것이다.
본격 Mock 만들기 — CACHE_MANAGER
우리의 CACHE_MANAGER는 위에서 찾은것과 같이 set,get,del,reset을 수행하고, 다음과 같다.
이 때 주의깊게 살펴볼 것은 get을 통해 User를 반환하는데, 위에서 정의한 mockUserStub을 그 결과로 반환하는 것에 집중하자.
우리는 해당 CACHE_MANAGER를 Value 형태로 작성하여 사용할 것이다.
import { mockUserStub } from '../../user/test/stubs/user.stub';
export const CACHE_MANAGER = {
set: jest.fn().mockResolvedValue(true),
//* 위에서 정의한 Test용 가짜 User를 반환하고 있다!
**get: jest.fn().mockResolvedValue(mockUserStub()),**
del: jest.fn().mockResolvedValue(true),
reset: jest.fn().mockResolvedValue(true),
};
이제 가짜 CACHE_MANAGER를 만들었으니 이것을 우리가 수행할 test code에서 제공해야한다.
즉, redis-manager.controller.spec.ts의 모듈을 만드는 과정에서 해당 CACHE_MANAGER를 DI해줘야 한다. 우리는 **기능을 제공하기 때문에 provides 아래에 제공하면 된다.**
이 때 imports에 사용할 것인지 등은 우리의 코드에 필요에 따라 바꾸면 된다.
//* 변경 전
...
let service: RedisManagerService;
...
const moduleRef = await Test.createTestingModule({
providers: [
RedisManagerService,
],
}).compile();
service = moduleRef.get<RedisManagerService>(RedisManagerService);
...
//* 변경 후
import { CACHE_MANAGER as MOCK_CACHE_MANAGER } from '../__mocks__/redis-manager.service';
...
let service: RedisManagerService;
**let cache: Cache;**
...
const moduleRef = await Test.createTestingModule({
providers: [
**{
provide: CACHE_MANAGER,
useValue: MOCK_CACHE_MANAGER,
},**
RedisManagerService,
],
}).compile();
service = moduleRef.get<RedisManagerService>(RedisManagerService);
**cache = moduleRef.get(CACHE_MANAGER);**
...
이 때 provide할 대상에 대해 useValue, useClass, useFactory 등을 사용할 수 있는데, 그 차이는 다음과 같다.
useClass: 객체(제공자, 가드 등)를 재정의할 인스턴스를 제공하기 위해 인스턴스화될 클래스를 제공합니다.
useValue: 객체를 재정의할 인스턴스를 제공합니다.
useFactory: 객체를 재정의할 인스턴스를 반환하는 함수를 제공합니다.
이제 다시 한 번 npm test redis-manager.controller를 실행해 보자.
Unit Test 코드 작성하기
이제 실제 Redis가 잘 동작하는지, Redis에 정의된 setCache, getCache, delCache, resetCache를 테스트하는 코드를 작성하면 된다.
import { CACHE_MANAGER } from '@nestjs/common';
import { Test } from '@nestjs/testing';
import { Cache } from 'cache-manager';
import { User } from '../../user/data/user.schema';
import { mockUserDto, mockUserStub } from '../../user/test/stubs/user.stub';
import { RedisManagerService } from '../redis-manager.service';
import { CACHE_MANAGER as MOCK_CACHE_MANAGER } from '../__mocks__/redis-manager.service';
describe('RedisManagerController', () => {
let service: RedisManagerService;
let cache: Cache;
const key = 'file/yes-data';
beforeEach(async () => {
const moduleRef = await Test.createTestingModule({
providers: [
{
provide: CACHE_MANAGER,
useValue: MOCK_CACHE_MANAGER,
},
RedisManagerService,
],
}).compile();
service = moduleRef.get<RedisManagerService>(RedisManagerService);
cache = moduleRef.get(CACHE_MANAGER);
});
it('then it should be defined', () => {
expect(service).toBeDefined();
});
describe('when setCache is called', () => {
let data: boolean;
beforeEach(async () => {
data = await service.setCache(key, mockUserDto as User);
});
test('then it should call redis.set', () => {
expect(cache.set).toBeCalledWith(key, mockUserDto as User);
});
test('then it should return a "true"', () => {
expect(data).toEqual(true);
});
});
describe('when getCache is called', () => {
let data: User;
//* Call the function through the controller
beforeEach(async () => {
data = await service.getCache(key);
});
//* Controller may call the function through the service
test('then it should call redis.get', () => {
//* With the Given Parameter
expect(cache.get).toBeCalledWith(key);
});
//* And the result should be microServiceGetDataStub()
//* Which is Mock Data
test('then it should return a User Info', () => {
expect(data).toEqual(mockUserStub());
});
});
describe('when deleteCache is called', () => {
let data: boolean;
beforeEach(async () => {
data = await service.deleteCache(key);
});
test('then it should call redis.del', () => {
expect(cache.del).toBeCalledWith(key);
});
test('then it should return a "true"', () => {
expect(data).toEqual(true);
});
});
describe('when resetCache is called', () => {
let data: boolean;
beforeEach(async () => {
data = await service.resetCache();
});
test('then it should call redis.reset', () => {
expect(cache.reset).toBeCalledWith();
});
test('then it should return a "true"', () => {
expect(data).toEqual(true);
});
});
});
이전에 쓰던 To Do List를 폐기하고, NestJS MVC 환경에서 TDD를 수행하는 법을 작성하려 한다.
크게 Unit Test와 Integration Test로 나누어서 연재할 예정이다.
간략한 MVC
흔히 서비스의 프론트엔드에서 발생하는 요청을 처리하기 위해 우리는 백엔드의 시스템을 MVC 디자인 패턴을 이용해 설계하곤 한다. MVC 패턴을 이용해 디자인 하면 객체 지향 설계 및 개발이 쉬워지기 때문인데, 간략히 설명하면 Model, View, Controller 각각의 객체(시스템 컴포넌트)들은 각자의 책임과 의무에만 집중하면 되는, 쉽게 말해 시스템을 ‘분리’하여 설계하고 개발할 수 있기 때문이다.
NestJS에서는 Module, Controller, Service를 통해 쉽게 MVC Design을 이용하여 애플리케이션을 구현할 수 있다.
일반적인 MVC 모델에서의 각 역할은 다음과 같다.
Controller Frontend(View)에서 발생하는 요청에 따라 서버의 Model을 활용하여 알맞게 반환하는 로직을 수행한다. Model 시스템이 가지고 있는 데이터로, Database, File System, Analysis 등 서비스와 관련된 모든 데이터를 가리킨다. Service MVC 모델에는 없는 요소지만, 서비스 패턴으로 거의 함께 설계된다. 컨트롤러가 라우팅 기능(요청과 응답)에 집중할 수 있도록 실제 Model을 관리하는 비즈니스 로직을 수행한다.
이것을 NestJS에서는 Module을 통해 쉽게 설계할 수 있는데, 그 생김새는 다음과 같다.
데이터 관리에 더 집중하기 위해 Repository를 추가하여 사용하기도 한다.
이렇게 각각 설계된 모듈은 NestJS의 imports를 통한 Dependency Injection를 통해 사용 가능하다.
위 예시와 같이 UserModule이 캐싱 기능 사용을 위해 RedisModule이 필요하다면, 의존성 주입을 통해 사용할 수 있다.
@Module({
imports: [
ConfigModule.forRoot(),
//* Redis 기능 사용을 위한 Dependency Injection
**RedisManagerModule**,
//* Mongoose 기능 사용을 위한 D.I.
**MongooseModule.forFeature([{ name: User.name, schema: _UserSchema }]),**
],
controllers: [UserController],
providers: [UserService, UserRepository],
exports: [UserService],
})
export class UserModule {}
여기까지 NestJS가 어떻게 동작하는지 간략하게 알아봤다면, 쉬운 예시를 통해 NestJS에서 TDD를 어떻게 수행하는지 다음 장 부터 본격적으로 설명하기 전에 간략히 해 보겠다.
전체적으로 우리가 구현할 것은 User Module로, 사용자 정보를 관리하는 웹서버를 만들것이다. 최종적으로는 User Module에 Mongoose와 Redis Module을 연결할 것인데, 이에 대해 Unit Test와 Integration Test를 수행할 예정이다.
웹 서버는 RESTful API 서버를 만들 것인데, 관련된 내용은 아래 글을 확인해주면 감사하겠다.
먼저 Unit Test는 말 그대로 단위 테스트다. 우리가 어떤 기능을 설계할 때, 해당 기능이 동작해야 다른 기능이 완전하게 동작하는 것을 알 수 있다. 우리의 UserModule로 설명하면, Service가 죽을 경우 Controller는 어떤 요청을 받더라도 정상적인 응답을 할 수 없게된다.
즉 이러한 상황을 사전에 방지하기 위해, Controller, Service, Model이 모두 각각 잘 동작하는지 확인하는 것이 그 목적이다. 다시 말하면, Controller에 각 라우팅이 잘 되는지 확인하고, Service의 Model 접근 등 기능이 잘 동작하는지 확인하고, 최종적으로 Model 또한 잘 동작하는지 확인하는 것이다.
그런데, 우리 서버는 웹 서버이므로, Controller가 잘 동작한다는 것은 실제 외부 요청에 대해 응답이 잘 반환되는지 확인하는 것이다. 즉 Controller의 실질적인 동작 테스트는 e2e (End to End) 테스트 다시 말해 Integration Test를 통해 확인할 것이다.
Service가 잘 동작한다는 것은, Model로 부터 우리가 기대한 모델을 잘 가져와서 Controller로 잘 반환했다는 것이기 때문에, Controller에서의 Service 호출이 잘 동작하는 것을 확인할 것이다.
마지막으로, Model의 경우 Redis의 경우는 실제 테스트 코드를 작성할 것이지만, Mongoose는 생략하도록 하겠다. (결국 똑같기 때문에)
정리하자면 다음 테스트들을 수행할 것이다.
Controller와 Service 간의 Unit Test
Service와 Model 간의 Redis를 통한 Unit Test
e2e Test
정리가 길었다. 이제 진짜 간단히 어떻게 Nest에서 TDD를 수행하는지 확인해 보자.
우선, NestJS 프로젝트를 생성하면 기본적으로 jest가 함께 설치된다. jest와 관련하여 자세한 내용은 https://jestjs.io 여기를 확인해 주길 바란다.
다음 명령어를 통해 NestJS 아래에서 Module, Controller, Service를 생성하자.
nest g module user --no-spec
nest g controller user --no-spec
nest g service user --no-spec
초기 user 모듈만 설정한 상태
그러고 나면 위와 같은 구조를 갖게 된다.
src는 NestJS를 개발할 source directory고, 그 아래의 user directory가 우리가 실제 개발할 User 관련 코드가 작성될 경로이다.
NestJS에서 test를 수행할 때, 나는 다음과 같은 구조로 수행한다.
user 디렉토리(이하 도메인 디렉토리) 아래에 test폴더와 mocks폴더를 생성하는데, 그 역할은 다음과 같다.
test: 실질적인 테스트 코드가 작성될 디렉토리 test/stubs: 테스트 코드에 필요한 Mocking Data(Dummy Data)가 작성될 디렉토리 mocks: 테스트에 필요한 Mocking Providers가 작성될 디렉토리
본격적으로 간단한 테스트를 작성해보자. 우리는 다음과 같은 요청을 처리하는 것을 만들려고 한다.
[REQUEST]
GET: /user
[RESPONSE]
OK
이를 위해 먼저 라우터의 처리가 필요한데 이는 Controller가 담당하므로, user.controller.ts에 다음의 코드를 작성하자. 다음부터는 해당하는 함수 등 필요한 부분만 잘라서 작성하겠다.
import { Controller, Get } from '@nestjs/common';
@Controller('user')
export class UserController {
@Get()
getUser(): string {
return 'OK';
}
}
이 후 Postman 등 HTTP Request를 보낼 수 있는 툴(Get method기 때문에 Web Browser를 이용해도 괜찮다.)로 http://localhost:3000/user로 요청을 보내보자.
지금은 TDD의 처음이기 때문에, 곧바로 controller에 실제 요청을 보내보았지만, 앞으로는 테스트 코드를 먼저 작성하고, 그것이 통과되면 실제 요청(e2e test 등)을 할 것이다.
처음으로 돌아가서, 테스트 코드를 작성해야 하는데 어떤것이 필요할까?
현재 우리는 User Controller를 테스트하고싶다. 즉 외부의 요청 없이 User Controller의 어떤 함수가 호출되었을 때, 기대하는 값이 잘 반환되는지 확인하고싶다. 그렇다면 User Controller의 구성은 어떻게 될까?
이 포인트가 정말 중요한데, NestJS에서는 Module을 만들고, 해당 모듈로부터 컨트롤러, 서비스 등 제공되는(Providing) 기능을 사용하고, 따라서 Module을 먼저 구성해야한다. 이것이 이해 안간다면, NestJS의 Module을 확인해보길 바란다. (👉 https://docs.nestjs.com/modules)
그래서 우리는 test code에서도 먼저 mock user module을 구현해야 한다.
//* user.controller.spec.ts
import { Test } from '@nestjs/testing';
import { UserController } from '../user.controller';
import { UserService } from '../user.service';
describe('UserController', () => {
//* 사용할 Controller를 정의한다.
let controller: UserController;
//* 사용할 Service를 정의한다.
let service: UserService;
//* 이렇듯 우리가 테스트하는 대상이 사용하는 모든 것을 선언한다.
//* 매 테스트를 수행하기 전에, testing을 위한 module을 정의한다.
beforeEach(async () => {
const moduleRef = await Test.createTestingModule({
imports: [],
controllers: [],
providers: [],
//* Compile을 붙이는 이유는, 해당 모듈이 생성되어야 하기 때문이다.
}).compile();
});
});
여기서 중요한 것은, imports, controllers, providers를 무엇으로 채우냐가 중요한데, 그것은 현재 테스트하는 대상에 따라 바뀐다.
즉, providers 제공자는 우리의 대상인 UserController가 어떤것을 제공받아야 하는지, 다시 말해 어떤 의존성을 갖는지를 기준으로 작성하면되고, Controller는 Controller가 필요하다면 적으면 된다.
마지막으로 imports의 경우 해당 모듈의 환경을 적어주면 되는데, 예를 들어 Mongoose 혹은 Redis 등 필요한 외부 모듈 (Mocking하지 않은)이 가지는 환경을 적어주면 된다.
우리는 UserController를 테스트하기 위해, 반드시 UserController가 필요하고 아직까지 의존성은 존재하지 않으니, 다음과 같이 갱신해주자.
//* 매 테스트를 수행하기 전에, testing을 위한 module을 정의한다.
beforeEach(async () => {
const moduleRef = await Test.createTestingModule({
controllers: [UserController],
}).compile();
//* 이후 컴파일 된 module에서 controller 등 필요한 것을 구한다.
controller = moduleRef.get<UserController>(UserController);
// service = moduleRef.get<UserService>(UserService);
});
우리가 Unit Test할 때 수행하는 내용은 크게 다음과 같다.
해당 함수가 정상적으로 호출 되었는가?
해당 함수에서 필요로 하는 의존성 대상들이 정상적으로 호출 되었는가?
이 때 의존성 대상에 따라 해당 단계가 많아질수도, 줄어들 수도 있다.
해당 함수가 종료되면서 기대한 값을 반환했는가?
예외 처리는 잘 되는가?
우리는 아직 getUser() 함수를 통해 OK를 반환하는 것 밖에 없지만, 위 단계에 따르면 (1) 정상적으로 호출 되었는가? (2) 정상적으로 ‘OK’를 반환했는가? 를 확인할 수 있겠고, 해당 코드는 다음과 같이 작성할 수 있다.
//* getUser() 함수가 호출되었다면,
describe('when getUser is called', () => {
let response: string;
//* 응답 비교를 위해 일단 직접 호출하여 응답을 저장하자.
beforeEach(() => {
//* controller의 getUser 함수를 관찰하자.
jest.spyOn(controller, 'getUser');
response = controller.getUser();
});
//* controller.getUser 함수가 한 번 반드시 호출될 것이다.
test('it should call controller.getUser once', () => {
expect(controller.getUser).toBeCalledTimes(1);
});
//* controller.getUser 함수가 파라미터 없이 호출될 것이다.
test('it should call controller.getUser without parameter', () => {
expect(controller.getUser).toBeCalledWith();
});
//* controller.getUser 함수의 반환 값은 'OK'일 것이다.
test('it should return a value "OK"', () => {
expect(response).toEqual('OK');
});
});
Jest는 사람이 읽을 수 있도록 테스트 코드가 작성되고, 또한 나도 위에 주석을 통해 설명을 적었기 때문에, 더 자세히 설명하지 않고 오늘의 글을 마무리짓도록 하겠다.
어떤 수열의 연속 부분 수열에 같은 길이의 펄스 수열을 각 원소끼리 곱하여 연속 펄스 부분 수열을 만들려 합니다. 펄스 수열이란 [1, -1, 1, -1 …] 또는 [-1, 1, -1, 1 …] 과 같이 1 또는 -1로 시작하면서 1과 -1이 번갈아 나오는 수열입니다.예를 들어 수열 [2, 3, -6, 1, 3, -1, 2, 4]의 연속 부분 수열 [3, -6, 1]에 펄스 수열 [1, -1, 1]을 곱하면 연속 펄스 부분수열은 [3, 6, 1]이 됩니다. 또 다른 예시로 연속 부분 수열 [3, -1, 2, 4]에 펄스 수열 [-1, 1, -1, 1]을 곱하면 연속 펄스 부분수열은 [-3, -1, -2, 4]이 됩니다.정수 수열 sequence가 매개변수로 주어질 때, 연속 펄스 부분 수열의 합 중 가장 큰 것을 return 하도록 solution 함수를 완성해주세요.
제한 사항
1 ≤ sequence의 길이 ≤ 500,000
100,000 ≤ sequence의 원소 ≤ 100,000
sequence의 원소는 정수입니다.
입출력 예
sequence
result
[2, 3, -6, 1, 3, -1, 2, 4]
10
입출력 예 설명
주어진 수열의 연속 부분 수열 [3, -6, 1]에 펄스 수열 [1, -1, 1]을 곱하여 연속 펄스 부분 수열 [3, 6, 1]을 얻을 수 있고 그 합은 10으로서 가장 큽니다.
Description
솔직히 이게 3레벨이라 믿기지 않는 문제. 1레벨이면 충분할 것 같다.
설명에서 주어진 바와 같이 배열의 각 인덱스에 1과 -1을 번갈아가며 곱해준 것과 -1과 1을 번갈아가며 곱해준 것 중 연속 합이 큰 것을 고르면 된다.
DP를 이용해 쉽게 풀 수 있는데, 현재 값을 더 했을 때의 최대 값과 더하지 않았을 때의 최대 값을 비교하면 된다.
최대 값을 저장하기 위한 1차원 DP 배열을 선언한다.
long[] sum = new long[length]
주어진 예제를 이용해 설명해 보면
먼저 1, -1, 1, -1, … 을 곱한 배열은 다음과 같다.
[2, -3, -6, -1, 3, 1, 2, -4]
여기에 대해 0번 인덱스 부터 하나씩 옮겨가며 다음과 같이 비교한다.
if 문의 비교연산은 다음 의미를 갖는다.
이전까지의 합과 현재 합을 더했을 때, 0보다 큰가? 즉, 음수가 되지 않았는가에 대한 비교이다.
만약 0 이하라면, sum[i] → 0으로 설정하여 현재 인덱스 까지의 연산을 초기화한다.
