저번 포스팅에서는 테스트코드가 왜 필요한지, 어떻게 해야 좋은 테스트코드를 작성하는지에 대해 알아보았다. 그리고 이번에는 기능을 개발하는 방식과 협업에서 좋은 테스트 코드가 무엇인지 알아보도록 하자.
1. TDD
TDD(test-driven development)란, 선 개발 후 테스트 방식이 아닌 선 테스트 후 개발 방식의 프로그래밍 방법이다. 테스트가 기능의 구현을 주도하는 방법이며 이 얘기만 들었을땐, 기능이 없는게 어떻게 테스트를 하죠? 라고 생각할 수 있다. TDD는 아래와 같은 순서로 개발을 진행하게 된다.
TDD : RED - GREEN - BLUE
TDD는 RED 단계 -> GREEN 단계 -> BLUE 단계를 거쳐 하나의 기능을 구현한다.
1. RED : 실패하는 테스트 작성
먼저, 테스트코드에 검증을 하는 코드를 먼저 작성한다.
@DisplayName("유저 한명을 추가하면 사이트 목록에 유저가 추가된다.")
@Test
void add() {
Site site = new site();
// 구현되지 않은 add
site.add(new developer());
assertThat(site.getUser()).hasSize(1);
assertThat(site.getUser.get(0).getName()).isEqualTo("그릴리쉬");
}현재 site.add 에는 기능이 개발되지않아 null을 return 한다고 하였을때 해당 테스트는 당연하게 실패할 수 밖에 없다. 즉 기능 구현이 없는 최소한의 기능만 코드를 작성해두고 테스트 코드에서 검증 코드를 구현한다.
2. GREEN : 검증이 통과하게끔 어떤 방식으로든 기능을 구현
site.add가 해당 테스트 코드의 검증을 통과 할 수 있도록 어떻게든 기능을 구현한다.
해당 단계에서는 코드의 가독성이나, 효율성을 따지기 전에 테스트 코드의 검증을 통과하는데 목적을 둔다.
3. BLUE : 검증이 통과하는 선에서 기능을 리팩터링
GREEN 단계에서 구현한 코드는 오로지 검증만을 위해 구현된 코드이기에 코드의 가독성과 효율성이 떨어질 것 이다. 해당 단계에서 테스트코드의 검증이 통과하는 선에서 코드를 리팩터링하여 가독성을 향상시키고 효율성을 높인다.
TDD 개발 방법은 왜 필요한가?
🤔 TDD가 아닌 선 기능 개발 후 테스트 코드를 작성한다고 가정했을때, 아래와 같은 문제가 생길 수 있다.
- 테스트 코드를 작성하지 않는다.
- 이미 구현이 되었다고 생각하여 테스트 코드를 작성하지 않게되면, 리팩터링이 진행되거나 해당 기능을 공유하는 기능이 생기게 된다면 기존의 구현된 코드가 정상 작동 되지 않아도 이를 놓칠 수 있다.
- 특정 테스트 케이스만 검증하려 한다.
- 분명 우리는 해피 케이스와 예외 케이스를 검증해야 안정적인 기능을 구현할 수 있다. 근데, 기능을 먼저 개발하여 테스트 코드를 작성한다면 기능이 결과값을 예상한대로 도출하는지에 대한 해피 케이스만 작성할 수 있다.
- 잘못된 기능 구현을 즉각적으로 대처하지 못한다.
- 기능을 먼저 개발하고 테스트코드를 작성하다보면, 잘못된 부분이 하나씩 나오게 되면 그때마다 하나씩 찾고 다시 구현해야 한다.
💡 TDD 개발 방법을 통한 기능 구현이 가져오는 점
- 유연하고, 유지보수 하기 쉬운 테스트 코드를 작성할 수 있다.
- 쉽게 발견하기 어려운 다양한 케이스들을 발견하고 놓치지 않는다.
- 기능을 구현했을때 즉각적인 피드백을 받을 수 있다.
- 기능을 구현하였을때 더 과감한 리팩터링을 할 수 있다.
이렇듯, TDD는 관점의 변화를 가져온다. 선 기능 개발 후 테스트 코드를 작성하게 되면 테스트 코드는 기능을 검증하기 위한 보조 수단으로 보이지만, TDD를 통해 테스트와 기능 구현 코드가 함께 개선될 수 있다.
즉, 클라이언트 관점에서 즉각적인 피드백으로 코드를 개발할 수 있다.
2. 더 나아간다면
우리는 TDD를 적용하는 것은 물론 여러 방식에 대응하여 개발을 할 수 있다. 아래와 같은 개념을 간단하게 살펴보자면
- 애자일 방법론
: 일정한 주기를 가지고 빠르게 제품을 출시하여 고객의 요구사항, 변화된 환경에 맞게 요구를 더 하고 수정해나가는 탄력적인 방법이다. 즉, 기능이 구현되었을때 클라이언트의 요구 사항을 받아들이면서 기능을 더 추가하거나 수정하는 방법이다.
- 폭포수 방법론
: 한단계씩 진행함에 따라 다시 이전 단계로 가지 않고 계속 진행하기에 다음 단계로 가기전에 완벽하게 요구사항을 반영하는 방법이고, 이는 하나의 기능을 완벽히 구현하여 한단계씩 완성해 나가는 방법이다.
비즈니스에 맞추어 TDD를 적용하고 여러 방법론을 통해 기능을 구현해 나아갈 수 있다. 또한 스크럼을 진행하거나 칸반과 같이 구체적인 프로세스를 갖추어 기능을 구현해 나아갈 수 있다.
다음 포스팅에서는 BDD에 대해 알아보도록 하자 !
