TDD 전문가들은 TDD가 테스트에 관한 것이 아니라 디자인에 관한 것이라고 점점 더 많이 알려줍니다 . 그래서 저는 TDD없이 정말 훌륭한 디자인을 만드는 일부 개발자들을 알고 있습니다. 그러면 TDD를 연습해야합니까?
답변
TDD는 최고의 디자인을 완성하는 데 도움이 될뿐 아니라 더 적은 노력으로 더 많은 도움을받을 수 있습니다.
어떤 디자인이 가장 좋을지 결정하기 전에 문제에 2 개 또는 3 개의 찌르기가있었습니다. 이제 정확히 같은 시간에 테스트를 작성하고 올바른 디자인에 집중합니다. 그리고 보너스로 반복 가능한 테스트 모음이 있습니다. 승리!
즉, TDD가 아무것도 제공하지 않는 사람들이있을 것입니다. 그들이 끝날 때 자동화되고 반복 가능한 테스트를 계속 가지고 있다면 괜찮습니다.
답변
이 특정 TDD 전문가가 실제로 말하려는 것은 TDD가 설계 프로세스 라는 것이 아닙니다 (많은 사람들이 불행히도 그렇게 해석하지는 않았지만). 여기서 메시지는 TDD와 같은 프로세스를 올바르게 사용 하면 전체 디자인을 향상시키는 경향이 있다는 것입니다.
기본 개념은 TDD보다 훨씬 오래된 개념입니다. 테스트 가능성을위한 설계 . SOLID 원칙, 특히 단일 책임 원칙 을 엄격하게 준수하면 코드를 매우 쉽게 테스트 할 수 있습니다. 당신이 당신의 디자인에 비트 sloppier 경향이 경우 반면에, 당신은 아마의 좌절을 피하기 위해, 더 자주이 작업을 수행하도록 강요하는 단위 테스트를 작성하는 과정을 찾을 수의 (a) 파악 무엇 에 필요 (b) 실제 테스트를 작성하는 것보다 종속성을 설정하는 데 더 많은 시간을 소비합니다.
당신은하지 않습니다 이 이 혜택을 얻기 위해 TDD를 따라하지만, 하지 테스트를 작성하는 도움을 초기 – 당신이하지 않을 경우 전이나 도중, 클래스를 구현하는 것이 바람직 곧 후. 너무 오래 기다리면 저자가 말하고있는 “더러운 하이브리드”테스트의 위험이 있습니다.이 테스트는 취하기 쉽고 무해한 리팩토링 중에 깨지기 쉬우므로 큰 가치가 없습니다. 규모는 매우 어려운 과정을 재 설계합니다.
테스트를 작성하지 않으면 실제로 테스트 가능성을 설계하고 있는지 알 수 없으며 15 % 코드 적용 범위의 “기능 테스트”는 포함되지 않습니다.
물론 단일 테스트를 작성하지 않고도 좋은 디자인을 만들 수 있습니다. 그러나 훌륭한 디자인이라고 확신하십니까? 테스트에 의해 명확하게 지정되지 않은 경우 어떻게 알 수 있습니까? 테스트는 많은 문제를 찾아 내고 QA 프로세스는 눈에 띄는 버그를 발견 할 수 있지만, 잘못된 디자인 결정 은 찾아 낼 수 없습니다 .
답변
당신은하지 않습니다 단순한 대답은 TDD를 배울하기 위해 노력하고 사람에서 오는 필요 로하지만, 당신을 제공하는 주요 혜택은 매우 간단하다 신뢰 : 응용 프로그램 작동하는지 신뢰. 유스 케이스가 만족된다는 확신. 논리가 “Foobar”모듈에 적합하다는 확신. CEO가 자신이 읽은 새로운 기능을 추가하고 싶을 때 6 개월 동안 코드를 유지 관리하고 확장 할 수 있도록 코드가 올바르게 구성되어 있다는 확신 애플리케이션이 커질 때 아키텍처가 무너지지 않도록하거나 새로운 기능을 배심원 조작하기 위해 지저분한 해킹이 필요하다는 토대를 마련했습니다.
위의 내용은 약간 복음적인 것으로 들리지만 TDD의 이점을 보는 방식입니다. TDD를 사용하여 우수하고 견고한 아키텍처 설계를 만들 수 있다고해도 손으로 일을 올바르게 수행 한 다음 일이 올바르게 완료되었음을 증명할 수 있으며 더 중요한 것은 일을 올바르게 유지 하기위한 기준을 제공합니다 . 내가 TDD에 푹 빠져서 작은 코드를 사용하면 코드를 깨끗하게 만들고 적절한 소프트웨어 엔지니어링 개념을 따르도록 강요했다. 그렇지 않으면 “가장 빠른 것”을 수행하는 경우가 많았다.
답변
나는 내 경험으로 만 이야기 할 수 있습니다. 저에게 TDD는 개발 스타일 습관 도구 상자에 없었던 몇 가지 사항을 가져 왔습니다. 그러나 TDD가 모든 것에 대한 해결책은 아니라고 다시 말할 가치가 있습니다. 항상 탐색과 프로덕션 준비 구현을 분리하려고합니다. 탐사 단계의 TDD는 절대적으로 필요하지 않으며 심지어 속도가 느려집니다. 프로덕션 준비 코드의 다른 측면에서는 단기 및 장기적으로 개발자의 정신 건강과 프로젝트의 업에 매우 유용한 몇 가지 이점을 제공합니다.
- TDD는 구현하기 전에 생각하게 만듭니다. 일반적으로 많은 촬영을 방지하고 솔루션을 잊어 버리는 매우 좋은 연습입니다.
- 그것은 문제의 작은 부분에 대해 생각하게하며, 함께 맞는 작은 조각에 대한 해결책을 깨뜨립니다.
- 문제에 맞지 않는 것을 스터브 / 모의 / 가짜로해야만 할 때마다 자연스럽게 하나의 “WTF를 던지는데, 왜 그렇게하지 않아도됩니까?” . 그리고 그것은 사물 사이의 연결을 더 잘 깨닫게 해줍니다.
- 내 코드에 대해 쉽게 실행 가능한 검사를 제공하므로 고통스러운 “var_dump”, “p”, “pp”, “echo”코드 디버깅 스타일을 거칠 필요가 없습니다. 그것은 단지 무엇이 잘못되었는지, 언제 잘못되었는지를보고합니다. 그리고 아직 확인하지 않으면 간단한 테스트를 반복하여 확인하는 것이 중요합니다.
- 배포하기 전에 모든 테스트를 통과하면 코드가 작동하는지 확인합니다. 그런 다음 손톱을 먹는 대신 케이크를 먹고 커피를 마시고 오후를 즐깁니다.
- 높은 수준의 테스트는 무언가를 리팩토링해야하는 경우에 매우 좋습니다. 내 모듈이 외부에 일부 기능을 제공해야하고 올바르게 작동하는지 입증하기 위해 기능 / 통합 / 오이 테스트를 개발 한 경우 해당 코드에서 지옥을 리팩토링하는 것이 매우 용감합니다. 여러 번 테스트를 거치지 않았고 리팩터링해야하는 코드에 직면했습니다. 이 경우 실제로 두 가지 방법이 있습니다. 1) 코드를 삭제하십시오. 2) 변경 사항을 건너 뛰고 그대로 유지하십시오.
TDD로 해결되지 않는 것이 있습니다. 당신이 짓고있는 것을 만드는 법을 모른다면, TDD는 당신을위한 해결책을 만들지 않을 것입니다. 문제 및 솔루션에 대한 대략적인 “디자인”또는 개요가 필요합니다. TDD는 더 높은 품질의 코드로 더 우아하고 유지 관리 가능한 방식으로 구현할 수 있습니다.
마지막으로 TDD 관행에 의존하는 BDD 용어로 생각하는 것을 선호합니다. BDD를 사용하면 도메인 어휘를 사용하여 솔루션을 구현하고 소프트웨어를 문제에 더 잘 맞출 수 있습니다.
답변
훌륭한 디자인을 달성하는 데는 여러 가지 방법이있을 수 있으며, “훌륭한”또는 “좋은”구성 요소에 대한 다양한 해석이있을 수 있습니다. 나는 대부분의 TDDers가 정의에 대해 당신과 동의하지 않을 것이라고 생각합니다. 우리가 생각하는 코드를 보아도 좋을 것이라고 생각합니다. TDD는 우리를 매우 특정한 특성으로 이끌어 주며, 이러한 특성은 TDD 이외의 코드에서는 거의 발견되지 않습니다.
테스트 가능성은 분명히 그 특성 중 하나이며 가장 중요한 특성입니다. 매우 작은 메소드 및 클래스는 아마도 하위 특성 일 수 있으며, 이는 탁월한 이름 지정으로 이어집니다. 어쩌면 TDD를 수행하지 않고 이러한 자질을 얻는 프로그래머를 알고있을 것입니다.