TDD (Test-Driven-Development)

TDD란

TDD는 코드를 작성하기 전에 단위 테스트를 작성하고, 해당 테스트를 통과시키기 위한 최소한의 코드를 작성한 후, 리팩토링하는 개발 방법론이다. 이 과정은 테스트가 실패한 것을 확인한 뒤, 테스트를 통과시키기 위해 코드를 수정하고, 다시 테스트와 코드를 개선하는 반복적인 사이클로 진행된다.

 

핵심은 프로덕션 코드보다 테스트 코드를 먼저 작성하는 데 있다. TDD의 궁극적인 목표는 작동하면서도 깔끔한 코드를 작성하는 것이다.

 

TDD 사이클

 

1. 새로운 기능을 위한 시나리오 나열
2. 시나리오에 대한 테스트 작성
3. 모든 테스트를 실행해 새로운 테스트가 실패하는지 확인
4. 테스트를 통과하기 위한 최소한의 코드 작성
5. 모든 테스트가 통과되도록 수정
6. 리팩토링을 통해 코드 개선

이 과정을 새로운 기능마다 반복한다.

---

TDD의 세 가지 규칙 (밥 마틴)

1. 실패하는 테스트를 먼저 작성한다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 테스트 코드를 작성한다.
3. 현재 실패하는 테스트 코드가 통과된 코드만 실제 코드에 작성한다.

 

 

 

이 세 단계에서는 흔히 Red - Green - Refactor로 요약된다. 먼저 테스트 목록을 작성하고, 이를 하나씩 선택해 각 테스트에 대한 해당 단계를 적용한다. 

• Red 단계에서는 '실패하는 테스트 코드'를 먼저 작성한다.
• Green 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
• Yellow 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.

중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것이다. 

 

테스트를 먼저 작성하는 것은 두 가지 주요 이점이 있다.

• Self - Testing Code: 테스트를 통과해야만 코드를 작성하므로, 테스트가 자동으로 검증역할을 한다. 
• 인터페이스 설계: 테스트를 먼저 작성하면 인터페이스에 집중하게 되어, 구현과 인터페이스를 분리하는 좋은 설계를 유도한다.

가장 흔한 TDD 실패 원인은 세 번째 단계인 리팩토링을 무시하는 것이다. 코드를 정리하지 않으면 코드가 복잡해지고 유지보수가 어려워질 수 있다. 

---

TDD 접근 방법

가짜로 구현하기

처음에는 테스트를 통과하기 위해 가짜 값을 반환하고, 이후에 리팩토링을 통해 올바른 코드를 점진적으로 작성한다.

@Test
public void 곱하기테스트() {
    // given
    
    // when
    final int result = multiply(2, 3);
    
    // then
    assertThat(result).isEqualTo(6);
}

public int multiply(final int num1, final int num2) {
    return 6;
}

 

 

삼각 측량

다양한 입력 값을 가진 테스트를 작성해, 일반화하는 과정이다. 테스트 예시가 2개 이상일 때만 추상화를 해야 한다.

@Test
public void 곱하기테스트() {
    // given
    
    // when
    final int result1 = multiply(2, 3);
    final int result2 = multiply(4, 7);
    
    // then
    assertThat(result1).isEqualTo(6);
    assertThat(result2).isEqualTo(28);
}

 

 

명백하기 구현하기

가짜 구현이나 삼각 측량 방법을 사용하지 않고 바로 정답을 구현하는 방법이다. 간단한 문제라면 바로 올바른 구현을 작성한다.

public int multiply(final int num1, final int num2) {
    return num1 * num2;
}

---

TDD 접근 방식

• Inside out (클래식): 작은 단위부터 테스트를 작성하며, 자연스럽게 아키텍처가 형성된다.
• Outside in (모키스트): 사용자 인터페이스부터 시작해 내부로 들어가며 테스트를 진행한다. 모의 객체(Mock)를 많이 사용한다.

---

TDD 장점

 

• 코드 품질 향상: 코드를 깔끔하고 유지보수하기 쉽게 만든다.
• 디버깅 시간 단축: 테스트와 코드가 함께 작성되므로 디버깅 시간이 줄어든다.
• 설계 개선: 사용자 요구사항에 맞춘 더 나은 설계를 도출한다.

 

TDD 단점

 

• 시간 소요: 처음에는 테스트 작성과 유지보수가 시간이 많이 걸릴 수 있다.
• 테스트 환경 설정: 적절한 테스트 환경이 필요하다.
• 학습 곡선: TDD를 익히는 데 시간이 걸릴 수 있다.
• 코드 양 증가: 테스트 코드로 인해 코드베이스가 커질 수 있다.

 

---

TDD 활용 팁

• 테스트 더블(Mocks, Fakes) 등을 활용해 외부 의존성을 테스트에서 분리할 수 있다.
• 리팩토링 기법을 다양하게 사용하여 코드를 일반화하고 개선해 나가는 것이 중요하다.

 

 

 

 

참조

https://martinfowler.com/bliki/TestDrivenDevelopment.html

https://mangkyu.tistory.com/182

https://www.samsungsds.com/kr/insights/test-driven-development.html?referrer=https://wooaoe.tistory.com/33

https://ahea.wordpress.com/2018/09/10/%EC%84%A0%ED%83%9D%EC%9D%B4-%EC%95%84%EB%8B%8C-%ED%95%84%EC%88%98-tdd/

https://www.geeksforgeeks.org/test-driven-development-tdd/

https://tech.kakaopay.com/post/implementing-tdd-in-practical-applications/