TDD의 단위 테스트

Question

저는 TDD에 처음 접했고 첫 번째 질문은 모든 개발 된 구성 요소에 단위 테스트를 적용해야하는지 여부입니다. 단위 테스트가 많은 시간을 필요로한다는 것을 알았 기 때문에 요구하고 있습니다. 특히 요구 사항의 일부 변경 사항이 제공 될 때 특히 그렇습니다. 그래서 단위 테스트와 관련하여 TDD에서 모범 사례를 제안 할 수 있습니까?

Answer 1

TDD의 간단한 설명 three rules 표현 : 당신이 실패한 단위 테스트 통과를 확인하지 않는 한 모든 제품 코드를 작성할 수 없다

1. .
2. 단위 테스트를 실패 할만큼만 쓸 수는 없습니다. 컴파일 실패는 실패입니다.
3. 하나의 실패한 단위 테스트를 통과하기에 충분한 생산 코드를 작성하는 것은 허용되지 않습니다.

그리고 더 이상 설명 : http://jamesshore.com/Agile-Book/test_driven_development.html

그리고 더 깊이 설명 : http://www.growing-object-oriented-software.com/

Answer 2

TDD는 테스트가 구성 요소 개발을 유도한다는 것을 의미합니다. 먼저 구성 요소의 동작을 지정하는 단위 테스트를 작성한 다음 구성 요소를 구현합니다. 그래서 귀하의 질문에 대답하기 : 단위 테스트가 이미 구성 요소를 개발하기 전에 작성해야하기 때문에

, 모든 개발 구성 요소

없음에 단위 테스트를 적용해야합니다.

Answer 3

테스트는 코드의 개발 드라이브. TDD는 실제로 소프트웨어의 원하는 동작을 정의하는 데있어 모든 것을 테스트 할 수있는 것은 좋은 부작용입니다.

TDD에 좋은 글은 그냥 관찰 here

Answer 4

사용할 수 있습니다 - 당신은 내가 그 단위 테스트는에 사실 시간

의 많이 걸립니다 관찰

말했다 짧은보기. 그러나 잠시 동안 진행될 코드의 경우 추가 작업으로 시간을 절약 할 수 있습니다. 저는 수년 전 제가 한 프로젝트에서 단위 테스팅의 가치를 강조하면서 모든 사람들에게 "우리는 그 단계를 건너 뛸 시간이 없습니다."라고 말할 것이라고 말했습니다. 그리고 그것은 사실입니다. 테스터가 앱을 테스트하는 데 더 적은 시간을 들여서 버그 추적 프로세스를 통해 버그를 걷어차 며, 몇 주 또는 몇 달 후에 한 일을 기억하는 데 소요되는 시간을 줄여서 시간을 절약 할 수 있습니다. 버그를 발견하면 사용자는 더 적은 버그를 볼 수 있습니다. 즉, 깨진 앱의 경우 더 적은 시간을 들일 것입니다. 오전 2시에 전화로 더 적은 시간을 할애하여 사용자가 다음 날에 오기 전에 앱을 수정할 수 있기를 바랍니다.

모든 것이 경제적으로 온다. 생산에 들어가는 코드의 경우, 나를 믿으십시오. 그 단계를 건너 뛸 시간이 없습니다. 시간과 회사 비용이 더 많이들 것입니다.

코드가 돋보이 지 않으면, 즉 작업을 돕기 위해 작성한 유틸리티이거나 네트워크 계층이 실제로 어떻게 작동하는지 확인하면 필요에 맞게 수행 할 테스트의 양을 조정할 수 있습니다. 경험을 통해 올바른 금액을 알 수 있도록 안내해드립니다.