우선 TDD의 정의는, 아래와 같다.
테스트 주도 개발은 Test-Driven Development의 약자로,
테스트가 코드 작성을 주도하는 개발 방법이다.
작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.
TDD 진행 단계
- 테스트 코드 작성: 먼저 작성할 기능에 대한 테스트 코드를 작성한다. 이때, 실패할 것으로 예상되는 테스트를 작성한다.
- 테스트 실행: 작성한 테스트 코드를 실행하고, 테스트가 실패하게 된다.
- 기능 구현: 테스트가 성공하도록 기능을 구현한다.
- 리팩토링: 구현한 코드를 리팩토링하여, 테스트가 성공하는지 확인한다.
TDD 사용 시 장점
- 안정성 증가: TDD는 테스트를 먼저 작성하므로, 코드가 기대한 대로 작동하는지 항상 확인할 수 있다. 이는 소프트웨어의 안정성을 높여주는 효과가 있다.
- 결함 조기 발견: TDD를 이용하여 코드를 작성할 때 결함을 빠르게 발견할 수 있다. 따라서, 개발 초기에 결함을 발견하고 수정함으로써 코드의 품질을 향상시킬 수 있다.
- 문서화: TDD는 테스트 코드와 기능 코드를 함께 작성한다. 이때 테스트 코드가 기능 코드의 예제를 제공해주므로 코드를 더 쉽게 이해할 수 있게 된다.
TDD 사용 시 단점
- 생산성 저하: 코드 작성 전 테스트 케이스를 작성해야 하기에, 이는 추가적인 시간과 노력이 필요하게 된다.
- 설계의 복잡성 증가: 코드가 테스트 케이스를 통과하도록 구현해야 하므로, 코드의 구조와 설계를 더욱 신중하게 고민해야 한다.
TDD에서 사용되는 테스트 종류
유닛 테스트
소프트웨어의 최소 단위인 함수나 메서드를 테스트하는 것을 의미한다. 테스트 케이스를 작성하고, 그것이 예상한 대로 잘 동작하는지 확인한다.
React에서는, 아래와 같은 내용을 확인하게 된다.
- 컴포넌트가 잘 렌더링 되는지
- 컴포넌트의 특정 함수를 실행하면 상태가 원하는 형태로 잘 바뀌는지
- Redux의 Action 생성 함수가 Action 객체를 잘 만들어내고 있는지
- Redux의 리듀서에 상태와 액션 객체를 넣어 호출하면 새로운 상태를 잘 만들어 주는지
통합 테스트
둘 이상의 컴포넌트 혹은 모듈이 함께 작동하는 방식을 테스트 하는 것을 의미한다. 즉, 시스템이 전체적으로 예상한 대로 동작하는지 확인한다.
React에서는, 아래와 같은 내용을 확인하게 된다.
- 여러 컴포넌트들을 렌더링했을 때 문제 없이 잘 실행되고 있는지
- DOM이벤트 발생 시 해당되는 컴포넌트들이 잘 을 확인하게 된다. 있는지
- Redux와 연동된 컨테이너 컴포넌트의 DOM에 특정 이벤트 발생 시 원하는 Action이 잘 Dispatch되는지.
그래서 이거 써요?
다른 블로그 글을 보거나, 여러 매체를 확인해 보면 TDD가 항상 옳은 것은 아닌 것 같다. TDD를 적용하면, 코드의 품질을 높일 수 있고 조기에 오류나 결함을 발견할 수 있다는 장점은 뚜렷하지만, 초기 개발 단계에서 테스트 코드 작성을 위한 추가적인 노력과 시간을 필요로 한다는 점에서 적용할 때 신중하게 생각해 봐야 할 것 같다.
