NestJS라는 안써본 프레임워크도 배워가며 동시에 TDD로 간단한 시나리오를 개발해보았다.
Jest를 사용하여 테스트 중에서도 유닛테스트만 일단 해보았다.
유닛테스트는 서비스나 레포지토리의 각 메소드 단위로 테스트하는 것이라 보면 될 것같다.

초기 작업

src                                        
├─ __tests__ //유닛테스트 디렉토리
│  └─ moduleA    
│     ├─ service.test.ts //모듈A의 서비스 테스트코드
│     └─ repository.test.ts //모듈A의 레포지토리 테스트코드
├─ module                                  
│  └─ moduleA                                                      
│  │  ├─ api                               
│  │  │  ├─ controller.ts
│  │  │  └─ dto.ts  
│  │  ├─ data
│  │  │  ├─ db.ts //실제 레포지토리
│  │  │  └─ entity.ts                                                                    
│  │  ├─ domain                            
│  │  │  ├─ model.ts
│  │  │  ├─ repository.ts //인터페스로 구현된 레포지토리
│  │  │  └─ service.ts                                           
│  │  ├─ error.ts                             
│  │  ├─ mapper.ts                                    
│  │  └─ module.ts
│  ├─ app.controller.ts
│  ├─ app.module.ts
│  ├─ app.service.ts
│  └─ main.ts
├─ package.json                    
├─ tsconfig.json                 
├─ .gitignore              
└─ .env                                

디렉토리 구조는 이렇게 가져갔다.
nest에서는 controller나 service 등을 만들면 그것을 테스트하는 파일인 spec.ts를 그곳에 같이 생성해주는데 그렇게 하지 않고
우리 팀은 "tests" 라는 유닛테스트용 디렉토리를 따로 만들어 거기 모아두었다.
그리고 tsconfig.json 파일에

"exclude": ["./src/__test__"]

을 추가해서 컴파일 시에 저 테스트 디렉토리는 포함시키지 않도록 하였다.

Jest Runner라는 익스텐션을 설치하여 원하는 테스트만 하나하나 쉽게 실행해볼 수 있게 하였다.

유닛테스트 맛본 후기

describe('CounselingController', () => {
  let controller: CounselingController;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      controllers: [CounselingController],
    }).compile();

    controller = module.get<CounselingController>(CounselingController);
  });

  it('should be defined', () => {
    expect(controller).toBeDefined();
  });
});

Nest에서 자동으로 생성해주는 테스트파일의 기본 골격이다.
사용법 자체는 나중에 가보니 별로 어려울 건 없는 것 같다.

더 어려웠던 점은 이 테스트코드란 것을 정말 필요성 있게 사용하는 방법인 것 같다.

가짜 데이터와 가짜 함수를 만들어서 테스트하란 것에서 부터 처음엔
가짜로 테스트를 한다면 이게 무슨 의미가 있는 것이지? 란 생각이 들었었다.
지금 이해하기로는 서비스를 테스트할 때는 서비스 단의 동작만을 테스트할 것이므로 서비스에서 호출하는 레포지토리는 가짜여도된다는 뜻인 것으로 이해된다.
그래서 서비스에서 호출하는 레포지토리의 메소드들은 일단 잘 동작한다고 가정하고 가짜로 만들어서
서비스의 로직만을 테스트하는 것이다.

저것을 받아들인 후에도 여전히 어떻게 테스트코드를 짜야 이게 정말 유용하게 쓰일까란 고민은 계속 들었는데, 아마 지금 우리가 써먹어보려고 한 시나리오가 너무 간단한 경우여서 서비스단에서 할게 별로 없어서 그런 의문이 든게 아닐까란 결론을 지었다.
실제 현업에서의 복잡한 기능을 구현해야한다면 테스트할 게 더 많을 것이다.
그럴 땐 테스트주도 개발이 더 효과적으로 쓰일 구석이 많을 것이란 생각이 들었다.
지금은 일단 간단한 유효성 검사 정도만 하며 맛보기만 해보았다.