1. TDD
•
TDD는 Red, Green, Refactor라고 하는 세 단계를 거쳐 소프트웨어를 개발하게 된다.
◦
Red 단계
▪
이 단계에서는 아직 구현되지 않은 기능을 테스트하는 케이스를 작성한다. 즉 명세에 대한 테스트를 먼저 작성한다.
▪
이 시점에서 테스트는 실패할 수 밖에 없기 때문에 이 단계는 테스트가 실패한다는 의미를 담아 Red 단계라고 부른다.
◦
Green 단계
▪
두 번째 단계인 Green 단계에서는 테스트를 통과하기 위한 최소한의 코드를 작성한다.
▪
이 단계에서는 코드의 품질을 신경쓰지 않는다. 오롯이 요구사항에 맞는 최소한의 기능을 개발해 테스트를 통과시키는 데만 집중한다.
◦
Refactor 단계
▪
여기서는 Green 단계에서 작성한 코드를 리팩토링하며 Blue 단계라고 불리기도 한다.
▪
여기서는 코드의 가독성과 유지보수성을 향상하는데 집중한다.
▪
이때 중요한 점은 기능은 유지된 상태에서 코드의 구조만 변경해야 한다는 점이다. 따라서 테스트에 통과하는 상태를 유지해야 하기 때문에 테스트가 보장된 상태에서 이뤄진다.
•
이는 테스트를 강제함으로써 설계에 도움을 주어 생산성을 유지할 수 있게 하지만 특정 시점이 되기 전까진 생산성이 그리 높지 않다는 단점이 존재한다.
•
이 역시 모든 문제를 해결해주지 않으며 무조건 좋은 방법론이 아니다.
2. BDD
•
TDD에서 파생된 소프트웨어 개발 방법론으로 TDD에 사용자 행동이라는 가치를 덧붙이고 이를 강조한다.
•
따라서 BDD에서는 사용자 행동을 행동 명세같은 요구사항으로 먼저 만들고 이것이 테스트로 표현될 수 있게 만든다. 즉 테스트가 요구사항에 관한 명세가 될 수 있게 만드는 것이다.
•
BDD는 TDD에 테스트 대상을 어떻게 테스트 해야 하는지 설명을 추가한 것이다. 즉 테스트 대상, 객체의 책임을 어떻게 검증하고 확인할 지가 추가된 개발 방법론이다.
•
이때문에 저자는 TDD와 DDD의 조합이라고 얘기한다. 때문에 BDD는 DDD의 속성인 이해관계자 간의 협업 강조 등을 가지고 있다.
•
더불어 BDD는 공통된 언어를 바탕으로 요구사항 문서가 사용자의 스토리 기반으로 작성되어야 한다는 것을 강조한다.
•
정리하자면 BDD에서 강조하는 것은 크게 4가지다.
◦
개발자와 이해관계자 간의 협업
◦
행동 명세(사용자 스토리 기반의 요구사항) 작성
◦
행동 명세의 테스트화
◦
테스트의 문서화
