TDD 작성의 3원칙

1. 실패할 수 있는 테스트failing test가 있는 경우에만 production에 작성해라.

2. 실패를 나타내기에 충분한 정도의 테스트만 작성해라. → 내가 원하는 기능을 완전히 이해하는데에 도움이 된다.

3. 실패하는 테스트가 있다면, 그것이 성공하는 코드 정도를 작성해라.

   ⇒ 결국, 하나만 파지 말라는 것. 되돌아갈 수 있는 사이클을 확보하라는 것이다!

테스트의 과정

1. Wrtie a Failing Test Red Phase
2. Write code to make it pass Green Phase
3. Refactor Blue Phase 중복이 없어야 한다!

더 이상 테스트를 생각할 수 없다면 멈추는 것

+ Canon TDD

• 테스트 케이스의 리스트를 작성한다 > 하나를 뽑아서 > Failing Test를 작성한다 가 누락되었다.
• 테스트 리스트가 계속 갱신이 되어야 한다
• 기획서와 테스트케이스 리스트는 다르다.

  1. 기능 단위로 모아서 정리: spec 정의 - use case, user story

  2. Spec 의 instance (Scenario, 제일 중요한 것 부터 찾는다): Given-When-Then

  3. Test list 작성 행위 분석 단계 Behavior Analysis Phase (Interface Implementation Split)

     → 테스트 리스트는 중요한 순서대로 작성한다.

  4. Next most degenerated Test

     → 순서가 매우 중요한데, 가장 형편없는 테스트부터 하여 guard clause를 확보한다

     → 인터페이스 설계가 테스트케이스를 작성할 때 이루어진다

     → 테스트가 실패도 되는지 꼭 확인해봐야 한다.

  5. Kent beck 의 구현 전략

     1. 상수 리턴 → 변수 리턴
     2. 명백한 구현을 바로 입력
     3. 삼각측량 triangulation

  6. 데이터의 의도가 중요하며, assert를 꼭 추가한다.

  7. Optionally Refactor to improve the implementation design local Refactoring

  8. End Symmetry, Conceptual Integrity / Pattern / badsmells

테스트 작성의 Trigger?

• 클래스가 추가되거나, 메소드가 추가되어서가 아니라 기능과 행위의 변화external behavior
• 리팩터링은 테스트 추가를 해서는 안 된다! 같은 동작을 보장하는 게 맞는 것 🅾️