ATDD: 소프트웨어를 개발하기 이전, 기능이 제대로 작동하는지 검증하기 위한 인수 테스트를 먼저 작성하는 개발 방법론인수 테스트: 시스템이 인수기준을 만족시키는가와 고객이 시스템을 인수할 것인가를 결정할 수 있도록 행하는 형식 검사사용자 스토리: 고객의 관점에서 작성된 기능에 대한 구체적인 설명인수 조건: 인수 테스트의 검증 대상이다. 혼자가 아닌 모두 함께 논의하여 만들어진다.(비개발 직군 포함)- (하늘) 인수라는 것은 넘겨 받는 것인데.. 고객이 시스템을 인수할려면? 시스템이 요구사항을 잘 만족해야겠지?
- Classic TDD는 테스트를 추가하면서 점진적으로 알고리즘이 구체화된다.
- Triangulation을 강조-> 잉여 테스트를 만들어내는데, 리팩터링 시 제거되어야 한다고 함.
- 오버엔지니어링 위험
- London School TDD는 점진적으로 협력자를 찾게 된다.
- 테스트 더블에 의존적
- 프로덕션 코드와 강하게 결합된 테스트
- 2가지를 통합적으로 채택하는 것이 좋을 수 있다.
- (하늘) ATDD 사이클 내부에서 TDD 사이클이 또 있는 형태?
- ATDD를 성공적으로 적용하는 모든 팀은, 기본적인 접근법으로 시작해, 팀의 상황에 맞게 변경한다. (점진적인 도입)
- 형식에 매몰되지 말자. 처음부터 완벽한 방법이 존재할까?
- 팀원과의 대화, 생각에 대한 싱크를 맞추는 것.
- 문화를 지속시키는데 중요한 것은 필요성에 대한 공감, 지속적인 리뷰와 피드백이다. 처음부터 완벽하지 않아도 괜찮다.