TDD란 무엇일까
TDD란
Wikipedia 에서의 정의
테스트 주도 개발(Test-driven development, TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다. 이 기법을 개발했거나 '재발견' 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어준다고 말하였다
TDD를 하기 위해선 Unit Test가 뭔지 알아야 한다.
테스트라고 구글에 검색하면 보통 다음을 맞닥뜨리게 된다.
Unit Test (단위 테스트)
Integration Test (통합 테스트)
E2E Test
다른 것들은 제껴두고 쉽게 생각하면 Unit Test는 데이터베이스 등의 의존 없는 기능 또는 함수 단위에서의 테스트라고 할 수 있다. 단순히 Unit Test에 국한되어 TDD를 할 수 있는 것은 아니겠지만, 쉽게 설명 하기 위해 이번 글에서는 Unit Test를 이용한 TDD에 대해 알아보자.
그래서 TDD는 어떻게 하는 걸까
TDD의 핵심은 Test 코드를 먼저 작성한 뒤 이에 대응하는 Production 코드를 작성한다는 것이다. 다음과 같은 과정을 거친다.
Test 코드를 작성한다. 당연히 Production 코드에 별 내용이 없으므로 이 케이스는 실패할 것이다.
Test를 성공할 수 있는 최소한의 Production 코드를 작성한다.
작성한 Production 코드를 리팩토링한다.
다른 기능이나 함수들에 대해서도 1 ~ 3을 반복한다.
왜 귀찮게 코드를 2배로 작성해야할까
TDD를 도입하면 최소 단위의 기능을 구현하기 위해 코드를 작성하게 되는데, 이 과정에서 코드의 모듈화가 자연스럽게 진행된다. 또한 이 과정을 반복하면 마지막에 완성된 Production 코드는 개발자가 생각했던 대부분의 Test 케이스들을 거치게 된다. 이를 Test Coverage가 높아진다고 표현한다. 그렇다면 이후 요구사항이 변경되거나 유지보수를 진행할 때 Production 코드의 변경이 생겨도 테스트를 해보면 최소한 이전 코드들의 요구사항은 모두 만족시킨다는 마음의 평화와 자신감을 얻게 된다. 만일 테스트가 없이 기능을 추가한다면, 추가된 기능말고도 이전의 기능들이 모두 그대로라는 것을 어떻게 보증할 것인가? Production 코드의 모든 기능들을 직접 실행시켜보는 수밖에 없다. 그러므로 TDD는 잠깐의 귀찮음을 대가로 장기적으로 오히려 더 빠른 개발을 할 수 있도록 도와준다고 할 수 있다.
백문이불여일견이다
다음 편에서는 Java8, JUnit5 등을 이용해 실제로 어떤 식으로 개발을 진행하는지 간단한 콘솔 프로젝트를 통해 알아보자.
Last updated