[WIP] TDD 와 Test Code

TDD 개발 방식과 단위/통합 테스트, Jest 사용법을 소개하며 효과적인 테스트 코드 작성에 대해 알아봅니다.

오래전부터 TDD 에 대해 공부를 하려고 다짐했었지만, 항상 다음으로 공부를 미뤄왔었다. 회사에서는 NestJS 를 도입하고, 테스트 코드를 점점 추가하기 시작했다. 하지만 테스트 코드를 쓰면서 들었던 생각이, 테스트 코드에 대해 제대로 알지 못한 상태에서 테스트 코드를 써 나간다면, 오히려 쓰지 않는것이 낫겠다 라는 생각이 들었었다. 때로는 테스트 코드를 쓰면서 너무 당연한, 결과가 정해져 있는 테스트 코드를 쓴다 라는 느낌을 강하게 받았다. 테스트 코드를 쓰면서 스스로 좀 더 좋은 개발자라는 위안을 얻을 수는 있지만, 누군가에게는 허례허식으로 보일 수 잇다는 생각이 들었다. 이러한 생각이 들자, 더이상 TDD 와 Test Code 에 대해 공부를 미룰 수 없었다.

TDD 개발

통상적인 개발의 경우, 기능 설계 이후 바로 코드를 작성한다. TDD 의 경우, 기능 설계 이후 테스트 코드를 먼저 작성하고, 이 테스트 코드에 부합하는 코드를 작성한다.

Unit Test

소스 코드의 개별 단위 를 테스트하여 사용할 준비가 되었는지 확인하는 테스트 방법이다. 개발 라이프 사이클의 초기 단계에서 버그가 식별되므로, 버그 수정 비용을 줄이는 데에 도움이 된다.

왜 단위 테스트를 해야 하는가 ?

프로그램이 다양한 의존성을 지니고 있을 때, 다양한 의존성들은 제거한 상태에서 쉽게 로직을 테스트 할 수 있다. ex. DB 연결이 있어야만 로직을 수행할 수 있는 API 의 경우, DB Connection 부분을 mock 객체로 대체한 후에 테스트 할 수 있다.
의존성을 지니는 부분에서 버그가 나는 것을 방지하기 위해서, 의존성을 제거한 상태에서 테스트를 진행한다.

단위 테스트의 조건

독립적이어야 하며, 어떤 테스트도 다른 테스트에 의존적이면 안된다.
다른 의존성으로부터 격리되어야 한다. 예를 들어, axios 와 같이 테스트 대상이 의존하는 것을 다른 것으로 대체해야 한다.

Jest

실무에 도입한 테스트 라이브러리는 Jest 이다. Jest 는 Facebook 에서 개발한 테스트 라이브러리이며, 쉽게 단위 테스트, 통합테스트를 수행할 수 있게 해 준다.

Filename Convention

Jest 는 다음과 같은 파일명의 파일을 테스트 파일로 인식한다.

| 분류 | 값 | | --- | --- | | File | ${filename}.test.js/ts | | File | ${filename}.spec.js/ts | | Directory | __tests__ |

Jest 사용법

| 분류 | 값 | | --- | --- | | describe | 여러 관련 테스트를 그룹화 하는 블록을 생성한다. | | it | 개별 테스트 를 수행. 각 테스트는 하나의 문장으로 네이밍하는 것이 컨벤션이다. | | expect | expect 함수는 값을 테스트 할 때마다 사용된다. 단독적으로 사용되지 않고, matcher 와 함께 사용된다. | | matcher | expect 함수와 같이 사용되며, 값을 비교할 때 도움을 준다. | | jest.fn() | Mock 함수를 생성한다. 단위 테스트를 작성할 때, 테스트를 독립적으로 만들기 위해 mock 함수를 생성하여 테스트 코드를 작성한다. 또한, mock 함수는 이 함수에 어떠한 일들이 발생했는지, 다른 코드들에 의해 어떻게 호출되었는지를 기억할 수 있다. (Spy On)|

Integration Test

통합테스트는 모듈을 통합하는 단계에서 수행하는 테스트이다. 단위 테스트를 먼저 수행하여 모듈들이 잘 작동하는 것을 확인했다면, 이제 이 모듈들을 연동하여 테스트를 수행한다. 통합테스트는 1. 모듈들의 상호 작용이 잘 이루어지는지 검증하기 위해, 2. 통합하는 과정에서 발생할 수 있는 오류를 찾기 위해 수행한다.

목차
TDD 개발
Unit Test
Jest
    Filename Convention
    Jest 사용법
Integration Test

이것도 읽어보세요