TDD(Test Driven Development)

TDD 란?

• TDD 란 Test Driven Development 의 약자로 '테스트 주도 개발' 이라고 한다.
• 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 실제 코드에 추가하는 단계를 반복하여 기능을 구현한다.

TDD 의 적용 방법

• 예를 들어 클라이언트에게 제공한 프로그램에 “태어난 년도를 입력하면 현재 나이가 출력” 되는 기능이 있는데, 클라이언트가 “95년생을 입력하니까 31살이라는 잘못된 결과가 나옵니다(95년생 = 29살)” 라는 요청을 했다고 가정해보자. 이 문제를 TDD 방식으로 해결해보는 시나리오이다.
• 일반적으로 TDD 는 총 3단계의 테스트를 통해 하나의 이슈를 처리한다.
• assert(A, B) 메서드
  • A == B 이면 success 출력 후 테스트 종료
  • A ≠ B 이면 failure 출력 후 테스트 종료

1차 테스트

• 1차 테스트의 목적은 클라이언트가 “95년생 입력 → 31살 출력” 이라는 오류 플로우를 알려줬기 때문에 실제로 그렇게 나오는지를 먼저 테스트 해보는 과정이다.
• success → 테스트가 잘못된 것이다. 사용자는 분명히 잘못된 플로우를 정확히 제시했다. 즉, 사용자의 환경에서는 반드시 에러가 발생하고 있는 것이다. 따라서 failure 가 나오게끔 끊임없이 Test 메서드를 재작성 해야한다.
• failure → 테스트 성공. 잘못된 플로우가 진행되는 것을 테스트 코드를 통해 확인했다. 환경의 차이일 수도 있고, 로직의 문제일 수도 있고… 뭐 어쨌든 오류를 발견했기 때문에 이를 기반으로 실제 코드를 수정해준다(= getAge 메서드를 수정한다).

2차 테스트

• 1차 테스트가 끝났다면 바로 2차 테스트로 넘어간다.
• 2차 테스트의 목적은 수정된 실제 코드가 실제로 잘 수정됐는지를 다시 한 번 테스트 코드를 통해 확인하는 과정이다.
• failure → 테스트가 잘못된 것이다. success 가 나오게끔 끊임없이 실제 코드를 재작성 해야한다.
• success → 테스트 성공. 즉 실제 코드는 정상적으로 잘 수정됐다는 뜻이다. 지금은 수정만 된 상태기 때문에 코드를 리팩토링 해준 후 다음 단계로 넘어간다.

3차 테스트

• 2차 테스트가 끝났다면 바로 3차 테스트로 넘어간다.
• 3차 테스트의 목적은 리팩토링을 마친 실제 코드가 이제 배포 가능한 완전한 코드인지를 마지막으로 테스트 코드를 통해 확인하는 과정이다.
• failure → 테스트가 잘못된 것이다. success 가 나오게끔 끊임없이 실제 코드를 재작성 해야한다.
• success → 테스트 성공. 이제 모든 단위 테스트는 끝났고, 클라이언트의 요청에 맞게 실제 코드는 잘 수정되었다.

TDD 흐름도

TDD 개발 주기

• 위에 정리된 TDD 의 적용방법에서는 아래와 같이 생각하면 된다.
• 1차 테스트 = Red
• 2차 테스트 = Green
• 3차 테스트 = REFACTOR

TDD 를 왜 사용하는가?

1. 단위 테스트를 하기 때문에 디버깅 시간을 단축할 수 있다.
2. 단위 테스트를 하기 때문에 추가 구현에 용이하다.
3. 다양한 예외사항을 미리 고려할 수 있기 때문에 재설계 시간을 단축할 수 있다.
4. 코드가 클라이언트에게 도달하기 전에 문제가 없는지 진단할 수 있기 때문에 불안정성을 개선할 수 있다.

TDD 의 단점?

1. 가장 큰 단점은 생산성의 저하이다. TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어난다. 따라서 SI 프로젝트에서는 잘 사용하지 않는다.

어떤 상황에서 TDD 를 사용하는 것이 좋은가?

1. 클라이언트의 요구사항이 자주 바뀌거나 추가되는 경우
2. 처음부터 완벽한 설계가 어려운 프로젝트를 진행하는 경우
3. 내가 개발하고 나서 누가 이 코드를 유지보수할 지 모르는 경우

<aside> 💡 결론적으로 불확실성이 높은 프로젝트는 TDD 를 사용하는 것이 유리하다!!

</aside>

TDD 란?

• TDD 란 Test Driven Development 의 약자로 '테스트 주도 개발' 이라고 한다.
• 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 실제 코드에 추가하는 단계를 반복하여 기능을 구현한다.

TDD 의 적용 방법

• 예를 들어 클라이언트에게 제공한 프로그램에 “태어난 년도를 입력하면 현재 나이가 출력” 되는 기능이 있는데, 클라이언트가 “95년생을 입력하니까 31살이라는 잘못된 결과가 나옵니다(95년생 = 29살)” 라는 요청을 했다고 가정해보자. 이 문제를 TDD 방식으로 해결해보는 시나리오이다.
• 일반적으로 TDD 는 총 3단계의 테스트를 통해 하나의 이슈를 처리한다.
• assert(A, B) 메서드
  • A == B 이면 success 출력 후 테스트 종료
  • A ≠ B 이면 failure 출력 후 테스트 종료

1차 테스트

• 1차 테스트의 목적은 클라이언트가 “95년생 입력 → 31살 출력” 이라는 오류 플로우를 알려줬기 때문에 실제로 그렇게 나오는지를 먼저 테스트 해보는 과정이다.
• success → 테스트가 잘못된 것이다. 사용자는 분명히 잘못된 플로우를 정확히 제시했다. 즉, 사용자의 환경에서는 반드시 에러가 발생하고 있는 것이다. 따라서 failure 가 나오게끔 끊임없이 Test 메서드를 재작성 해야한다.
• failure → 테스트 성공. 잘못된 플로우가 진행되는 것을 테스트 코드를 통해 확인했다. 환경의 차이일 수도 있고, 로직의 문제일 수도 있고… 뭐 어쨌든 오류를 발견했기 때문에 이를 기반으로 실제 코드를 수정해준다(= getAge 메서드를 수정한다).

2차 테스트

• 1차 테스트가 끝났다면 바로 2차 테스트로 넘어간다.
• 2차 테스트의 목적은 수정된 실제 코드가 실제로 잘 수정됐는지를 다시 한 번 테스트 코드를 통해 확인하는 과정이다.
• failure → 테스트가 잘못된 것이다. success 가 나오게끔 끊임없이 실제 코드를 재작성 해야한다.
• success → 테스트 성공. 즉 실제 코드는 정상적으로 잘 수정됐다는 뜻이다. 지금은 수정만 된 상태기 때문에 코드를 리팩토링 해준 후 다음 단계로 넘어간다.

3차 테스트

• 2차 테스트가 끝났다면 바로 3차 테스트로 넘어간다.
• 3차 테스트의 목적은 리팩토링을 마친 실제 코드가 이제 배포 가능한 완전한 코드인지를 마지막으로 테스트 코드를 통해 확인하는 과정이다.
• failure → 테스트가 잘못된 것이다. success 가 나오게끔 끊임없이 실제 코드를 재작성 해야한다.
• success → 테스트 성공. 이제 모든 단위 테스트는 끝났고, 클라이언트의 요청에 맞게 실제 코드는 잘 수정되었다.

TDD 흐름도

TDD 개발 주기

• 위에 정리된 TDD 의 적용방법에서는 아래와 같이 생각하면 된다.
• 1차 테스트 = Red
• 2차 테스트 = Green
• 3차 테스트 = REFACTOR

TDD 를 왜 사용하는가?

1. 단위 테스트를 하기 때문에 디버깅 시간을 단축할 수 있다.
2. 단위 테스트를 하기 때문에 추가 구현에 용이하다.
3. 다양한 예외사항을 미리 고려할 수 있기 때문에 재설계 시간을 단축할 수 있다.
4. 코드가 클라이언트에게 도달하기 전에 문제가 없는지 진단할 수 있기 때문에 불안정성을 개선할 수 있다.

TDD 의 단점?

1. 가장 큰 단점은 생산성의 저하이다. TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어난다. 따라서 SI 프로젝트에서는 잘 사용하지 않는다.

어떤 상황에서 TDD 를 사용하는 것이 좋은가?

1. 클라이언트의 요구사항이 자주 바뀌거나 추가되는 경우
2. 처음부터 완벽한 설계가 어려운 프로젝트를 진행하는 경우
3. 내가 개발하고 나서 누가 이 코드를 유지보수할 지 모르는 경우

💡 결론적으로 불확실성이 높은 프로젝트는 TDD 를 사용하는 것이 유리하다!!