http://behaviour-driven.org/

1. The developer starts writing unit tests around their code using a test framework like JUnit or NUnit.
개발자는 JUnit 나 NUnit 같은 테스트 프레임 워크를 사용해서 자신의 코드를 테스트하는 코드를 작성하기 시작한다
2. As the body of tests increases the developer begins to enjoy a strongly increased sense of confidence in their work.
테스트가 늘어남에 따라 개발자는 자신의 작업결과에 대한 안정성을 확신할 수 있게 된다
3. At some point the developer has the insight (or is shown) that writing the tests before writing the code, helps them to focus on writing only the code that they need.
어떤 시점에 다다르면, 개발자는 코드를 짜기 전에 테스트를 짜는 것이 그들이 정말 필요로 하는 코드에 집중하는데 도움이 된다는 것을 깨닫게 된다.
4. The developer also notices that when they return to some code that they haven't seen for a while, the tests serve to document how the code works.
개발자는 또한 오랫동안 들여다보지 않았던 코드를 다시 봐야 할 경우, 테스트를 보면 코드의 실제 작동사항을 문서처럼 참고할 수 있다는 것을 알게 된다.
5. A point of revelation occurs when the developer realises that writing tests in this way helps them to “discover” the API to their code. TDD has now become a design process.
개발자는 테스트를 짜는 것이 그들의 코드의 API 를 '발견' 하는 과정이라는 깨달음을 얻는다. TDD는 이제 디자인 공정 그 자체가 된다
6. Expertise in TDD begins to dawn at the point where the developer realizes that TDD is about defining behaviour rather than testing.
개발자가 TDD 를 능숙하게 쓰게 되면 TDD 는 테스트를 하는 것이 아니라 행위를 정의하는 일이라는 것을 깨닫게 된다.
7. Behaviour is about the interactions between components of the system and so the use of mocking is fundamental to advanced TDD.
행위를 정의하는 것은 시스템의 구성요소간의 상호작용을 정의하는 것이고, mock 임시 오브젝트를 사용하는 것이 고수준의 TDD 의 필수요소화 된다

많은 개발자들이 TDD 를 받아들여서 4단계까지 발전하지만 거기서 멈추고 5,6,7 단계에 숨어있는 큰 장점까지 도달하지 못하는 현상이 있다고 지적하여 제시한 방식

http://www.deanberris.com/spec-cpp/