나는 내 경험으로 만 이야기 할 수 있습니다. 저에게 TDD는 개발 스타일 습관 도구 상자에 없었던 몇 가지 사항을 가져 왔습니다. 그러나 TDD가 모든 것에 대한 해결책은 아니라고 다시 말할 가치가 있습니다. 항상 탐색과 프로덕션 준비 구현을 분리하려고합니다. 탐사 단계의 TDD는 절대적으로 필요하지 않으며 심지어 속도가 느려집니다. 프로덕션 준비 코드의 다른 측면에서는 단기 및 장기적으로 개발자의 정신 건강과 프로젝트의 업에 매우 유용한 몇 가지 이점을 제공합니다.

• TDD는 구현하기 전에 생각하게 만듭니다. 일반적으로 많은 촬영을 방지하고 솔루션을 잊어 버리는 매우 좋은 연습입니다.
• 그것은 문제의 작은 부분에 대해 생각하게하며, 함께 맞는 작은 조각에 대한 해결책을 깨뜨립니다.
• 문제에 맞지 않는 것을 스터브 / 모의 / 가짜로해야만 할 때마다 자연스럽게 하나의 “WTF를 던지는데, 왜 그렇게하지 않아도됩니까?” . 그리고 그것은 사물 사이의 연결을 더 잘 깨닫게 해줍니다.
• 내 코드에 대해 쉽게 실행 가능한 검사를 제공하므로 고통스러운 “var_dump”, “p”, “pp”, “echo”코드 디버깅 스타일을 거칠 필요가 없습니다. 그것은 단지 무엇이 잘못되었는지, 언제 잘못되었는지를보고합니다. 그리고 아직 확인하지 않으면 간단한 테스트를 반복하여 확인하는 것이 중요합니다.
• 배포하기 전에 모든 테스트를 통과하면 코드가 작동하는지 확인합니다. 그런 다음 손톱을 먹는 대신 케이크를 먹고 커피를 마시고 오후를 즐깁니다.
• 높은 수준의 테스트는 무언가를 리팩토링해야하는 경우에 매우 좋습니다. 내 모듈이 외부에 일부 기능을 제공해야하고 올바르게 작동하는지 입증하기 위해 기능 / 통합 / 오이 테스트를 개발 한 경우 해당 코드에서 지옥을 리팩토링하는 것이 매우 용감합니다. 여러 번 테스트를 거치지 않았고 리팩터링해야하는 코드에 직면했습니다. 이 경우 실제로 두 가지 방법이 있습니다. 1) 코드를 삭제하십시오. 2) 변경 사항을 건너 뛰고 그대로 유지하십시오.

TDD로 해결되지 않는 것이 있습니다. 당신이 짓고있는 것을 만드는 법을 모른다면, TDD는 당신을위한 해결책을 만들지 않을 것입니다. 문제 및 솔루션에 대한 대략적인 “디자인”또는 개요가 필요합니다. TDD는 더 높은 품질의 코드로 더 우아하고 유지 관리 가능한 방식으로 구현할 수 있습니다.

마지막으로 TDD 관행에 의존하는 BDD 용어로 생각하는 것을 선호합니다. BDD를 사용하면 도메인 어휘를 사용하여 솔루션을 구현하고 소프트웨어를 문제에 더 잘 맞출 수 있습니다.

답변