2. TDD와 BDD는 어떻게 다른가?
• TDD가 먼저 나왔다.
• BDD는 TDD의 개념을 승계해서 탄생했다.
3. TDD는 왜 탄생했나?
• 테스트 코드 없이 그냥 개발하던 시절이 있었다.
• Kent Beck이라는 사람이 테스트로 검증된 코드로 실제 코드를 작성하자고 업계
에서 주장
• 이 사람 주도 하에 TDD가 발전
4. 개발 전에 테스트 코드를
먼저 쓰자는 TDD??
• 꼭 그렇진 않다.
• 문제를 정의하고 해답을 찾아가는 과정이라는 게 TDD의 기본 취지
• 개발자가 뭘 개발 해야되는지를 확실히 알고 개발하자는 게 TDD의 취지
• 테스트 코드는 그 철학을 이행하는 도구일 뿐
5. TDD는 테스트 코드를 어떻게?
• 유닛을 위한 테스트 셋을 정의
• 개발 코드로 유닛을 구현
• 마지막으로 유닛에 대한 구현이 테스트를 통과 하는지 검증
6. TDD의 기본 인터페이스
• 유닛을 위한 테스트 셋을 정의
• 개발 코드로 유닛을 구현
• 유닛에 대한 구현이 테스트를 통과 하는지 검
증
7. 테스트 코드를 먼저 짜고,
그 다음에 개발 코드를 짜는 건 맞지 않는가?
• 맞음
• Red - Green - Refactor 방식으로 진행
• 하지만 테스트 코드로 개발을 먼저 시작하자는 게 TDD의 기본 철학은 아님
8. 근데 왜 BDD가 나오게 되었나?
• TDD 개념으로 다른 개발자들에게 코치를 하던 Dan north라는 사람
• 어느날 TDD에서의 빈틈을 느끼기 시작
• 프로세스의 어디서 부터 시작해야 하는가
• 무엇을 테스트하고 또 무엇을 하지 말아야 하는가
• 한번에 얼마만큼 테스트해야 하는가
• 테스트를 어떻게 명명해야 하는가
• 테스트가 실패 하는 지에 대해 어떻게 이해해야 하는가
9. TDD의 한계를 느꼈다는 말인 것 같은데,
그럼 그 빈틈을 어떻게 해결하고자 했는가?
• 특정 값이 주어지고 (Given)
• 어떤 이벤트가 발생했을 때 (When)
• 그에 대한 결과를 보장해야한다 (Then)
• 위의 형식을 만들어서 테스트 코드를 짜기 시작
10. 그 형식을 쓰는 것만으로도
BDD라고 볼 수 있는 건가?
• Dan north는 애초에 Test라는 단어를 쓰지 않는 게 TDD의 원리를 더 파악하기
쉽다고 생각
• Test라는 단어보다는 Behavior 이라는 표현을 쓰는 게 더 낫다고 판단
11. 기존의 TDD 인터페이스에는 suit - test
형식이 있었는데 그럼 바뀐다는 말인가?
• test라는 단어를 없앰
• describe - it - should라는 패턴으로 변경
12. test라는 단어만 없고 결국 TDD
인터페이스랑 비슷한 것 같은데?
• 맞다. 둘다 별 차이가 없다.
• BDD는 기술 언어가 아닌 자연어에 가깝게 테스트 스펙을 기술한다는 것이 포인
트
• TDD와 BDD 중 뭐가 낫고 별로냐는 논쟁은 소모적인 논쟁
13. 결국 TDD와 BDD는 테스트 코
드 인터페이스만 다를 거 아닌가?
• 맞다.
• 둘 다 Red - Green - Refactor 흐름으로 진행
• given - when - then 패턴으로 테스트 코드가 작성된다고 보면 됨
