TDD의“명백한 구현”이 코드를 먼저 의미합니까?

저의 친구와 저는 비교적 새로운 TDD이며 "Obvious Implementation"기술 (Kent Beck의 "TDD By Example")에 대한 분쟁이 있습니다. 내 친구는 구현이 분명하다면 새로운 행동을 테스트 하기 전에 작성해야한다고 말합니다. 그리고 실제로 그 책은 말합니다 :

간단한 작업을 어떻게 구현합니까? 그냥 구현하십시오.

또한:

때로는 작업을 구현하는 방법을 알고 있습니다. 어서

필자는 저자가 의미하는 바는 먼저 "가짜 (Fake It ( 'Till You Make It)" "및 구현 단계에서 더 작은 단계를 요구하는 다른 기술과는 대조적으로 먼저 테스트 한 다음"그냥 구현 "해야한다는 것입니다. 또한이 인용문 후에 저자는 "명백한 구현"을 할 때 "빨간 막대"(실패한 테스트)를 얻는 것에 대해 이야기합니다. 어떻게 테스트없이 빨간 막대를 얻을 수 있습니까?.

그러나 나는 "명백한"이라는 책에서 여전히 먼저 테스트를 의미하는 인용문을 찾을 수 없었습니다.

어떻게 생각해? 구현이 "명확한"(TDD에 따라) 처음 또는 이후에 테스트해야합니까? 당신은 그냥 말하는 책이나 블로그 게시물을 알고 있습니까?

나는 당신의 해석에 동의합니다-그것은 여전히 ​​빨강 녹색 리 팩터이며, 리 팩터 비트 만 남았습니다.)

따라서 먼저 실패한 테스트를 작성한 다음 "가장 간단한"디자인을 천천히 구축하는 대신 확실한 솔루션을 구현하십시오.

당신은 그냥 말하는 책이나 블로그 게시물을 알고 있습니까?

나는 Beck의 책이 바로 그렇게 말합니다.

그는 계속해서 말합니다

그러나 명백한 구현 만 사용하면 완벽을 요구합니다. 심리적으로 이것은 파괴적인 행동이 될 수 있습니다. 작성한 내용이 테스트를 통과 할 수있는 가장 간단한 변경이 아닌 경우 어떻게해야합니까? 당신의 파트너가 당신에게 더 간단한 것을 보여 주면 어떨까요? 당신은 실패입니다! 당신의 세계는 당신을 무너 뜨립니다! 당신은 죽습니다. 넌 얼어 붙었 어

코드가 존재하기 전에 코드를 작성하여 테스트를 통과하려면 어떻게해야합니까?

분명히 여기에는 어렵고 빠른 규칙이 없으며 결국 민첩 해져서 반복 할 때 적응해야합니다. :)

부분적으로는 간단한 조작에 달려 있으며, TDD를 점점 더 많이 연습할수록 정기적으로 잘못 테스트했거나 실제로 전혀 테스트하지 않은 것들을 정기적으로 찾을 수 있습니다. 그것은 학습 곡선의 모든 부분입니다.

또한 TDD를 사용하면 라이브 코드에 커밋하기 전에 인터페이스와 구현을 테스트 할 수 있습니다.

당신은 무언가를 구현하는 방법을 알고 있지만 얼마나 자주 처음으로 완벽한 클래스 / 메소드 등을 작성 하는가는 길을 따라 약간의 조정이나 코드를 한 번 또는 두 번 및 6 개월 후에 단계별로 변경하여 무언가를 변경할 수 있습니다. 테스트의 샌드 박스에서 더 많은 자신감을 얻었습니다.

물론 테스트가 코드를 더 정확하게 작성한다는 의미는 아니지만 테스트가 변경 사항을 주도하고 테스트가 코드의 첫 번째 클라이언트가되며 테스트 비용이 매우 저렴하고 변경에 따른 위험이 적습니다. 개발하는 동안 더 많은 자신감과 자유를 누릴 수 있습니다.

당신이 정말로 좋은 커버리지와 더 높은 품질을 얻으려고 노력한다면, 더 많은 테스트를 시작할 필요가 있습니다. TDD를 더 많이 연습할수록 필요한 커버리지 수준에 대한 감각을 개발하게 될 것입니다.

나는 사소한 코드에 대해서는 단위 테스트가 전혀 없다는 것을 배웠다.

예 : 메소드를 로컬 변수에 매핑하는 java getter / setter 메소드가 있으면 이에 대한 단위 테스트가 과도하게 수행됩니다.

이것이 저자가 의미하는 것일 수 있습니다.

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."