[이규원의 현실 세상의 TDD: 안정감을 주는 코드 작성 방법] 7장: 테스트 주도 개발

본문은 Fastcampus의 [이규원의 현실 세상의 TDD]를 수강하고 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다.

 

테스트 주도 개발 절차

• RED
  • 실패하는 테스트 추가
• GREEN
  • 테스트 통과
  • 최소한의 코딩
• REFACTOR
  • 구현 설계 개선
  • 테스트 통과 유지

 

 

테스트 실패

1) 구체적인 하나의 요구사항을 검증하는 하나의 테스트를 추가

2) 추가된 테스트가 실패하는지 확인

• 실패하는 것을 확인해야 테스트가 제대로 동작함을 신뢰할 수 있다
• 운영 코드를 아직 변경하지 않았기 때문에 반드시 테스트가 실패하는 것을 확인해야 한다
• 실패의 이유도 중요하다. 테스트를 잘못 짜서 실패한 것이 아니라 운영 코드 미반영으로 인해 테스트가 실패해야 한다

 

 

테스트 성공

1) 추가된 테스트를 비슷해 모든 테스트가 성공하도록 운영 코드를 변경

2) 테스트 성공은 요구사항 만족을 의미

• 요구사항 만족은 코딩의 가장 중요한 임무

3) 테스트 성공을 위한 최소한의 변경

• 가장 중요한 임무를 가장 빠르게 완수
• 확장성의 유혹에 빠지면 테스트되지 않은 코드가 운영 코드에 들어갈 수 있음
• 테스트를 성공할만큼만 최소한으로, 빠르게 코드를 작성한다

 

 

리팩터링

• 코드베이스 정리
• 구현 설계 개선
  • 인터페이스를 바꾸는 것이 아님! 인터페이스는 클라이언트가 의존하고 있다 
  • 가독성, 정응성, 성능
• 모든 테스트 성공을 전제

 

 

켄트 벡의 설계 규칙

https://martinfowler.com/bliki/BeckDesignRules.html 참고

 

1) 테스트를 통과하라

2) 의도를 노출하라

• 3번과 상충될 수 있음
• 2번과 3번은 비슷한 우선순위를 지님 

3) 중복을 제거하라

4) 가장 적은 요소

• 앞의 3가지 규칙을 만족하는 데 필요하지 않은 코드는 제거하라
• 즉 테스트 통과에 필요한 코드가 아니면 제거하라

 

 

테스트 주도 개발 세부 흐름

테스트 주도 개발 세부 흐름

• 테스트 주도 개발은 낯설지 않다
  • 일반적인 개발 프로세스와 매우 유사하다
  • 버그 제보 -> 버그 재현 -> 코드 수정 -> 작업 완료 or 버그 재현 반복

 

 

테스트 주도 개발과 비용의 상관관계

• 비용과 시간을 고려하여 TDD를 도입해야 한다
• t2부터 TDD를 도입하는 게 비용적인 측면에서 유리하다
• 그러나 기술의 도입, 테스트 코드 작성의 단축 등으로 TDD 사용에 들어가는 비용이 낮아진다면 TDD 사용이 유리해지는 시점은 더욱 앞당겨진다