테스트 중심 개발 (TDD)은 실제로 실제 프로젝트에 도움이 되었습니까?

코딩이 처음이 아닙니다. 나는 15 년 넘게 (심하게) 코딩을 해왔다. 나는 항상 내 코드에 대한 테스트를 해왔다. 그러나 지난 몇 개월 동안 Ruby on Rails를 사용하여 테스트 중심 설계 / 개발 (TDD)을 배우고 있습니다. 지금까지는 이점이 없습니다.

몇 가지 사항에 대한 테스트를 작성하면 약간의 이점이 있지만 매우 적습니다. 테스트를 먼저 작성한다는 아이디어가 마음에 들지만 테스트를 디버깅하여 실제 코드를 디버깅하는 것보다 실제로 의미하는 바를 말하기 위해 더 많은 시간을 소비합니다. 테스트 코드가 테스트하는 코드보다 훨씬 더 복잡하기 때문일 수 있습니다. 사용 가능한 도구 ( 이 경우 RSpec) 를 사용하지 않았 으면 좋겠습니다 .

그러나이 시점에서 실망스러운 성능 부족과 혼합 된 좌절의 수준은 용납 할 수없는 수준입니다. 지금까지 TDD에서 볼 수있는 유일한 가치는 다른 프로젝트 / 파일의 템플릿으로 사용되는 RSpec 파일 라이브러리가 증가하고 있다는 것입니다. 실제 프로젝트 코드 파일보다 훨씬 유용하지는 않을 것입니다.

이용 가능한 문헌을 읽으면 TDD가 막대한 시간이 걸리는 것처럼 보이지만 결국에는 돈을 지불합니다. 그냥 궁금합니다. 실제 사례가 있습니까? 이 엄청난 좌절이 현실 세계에서 갚을 수 있습니까?

나는 여기 다른 곳 에서이 질문을 놓치지 않았기를 바랍니다. 검색했지만이 시점에서 모든 질문 / 답변은 몇 년 전입니다. TDD에 대해 나쁜 말을 할 개발자를 발견 한 경우는 드물기 때문에 이만큼 많은 시간을 보냈습니다. 그러나 아무도 실제 사례를 구체적으로 지적하지 않는 것으로 나타났습니다. 2011 년 코드를 디버깅하는 사람이 완전한 단위 테스트 스위트를 보유한 것에 대해 감사 할 것이라고 한 답변을 읽었습니다 (2008 년에 의견이 작성된 것 같습니다).

그래서, 나는이 세월이 지난 후에 마침내 그 대가가 현실이라는 것을 보여주는 예가 있습니까? 실제로 TDD로 설계 / 개발되었으며 완전한 단위 테스트 세트를 가지고 실제로 대가를 느낀 코드를 물려받은 사람이 있습니까? 또는 테스트가 무엇을 테스트하고 (그리고 왜 중요한지) 파악하기 위해 너무 많은 시간을 소비하고 있다는 것을 알게 되었습니까?

이 백서 는 TDD가 유사한 프로젝트에서 결함 밀도를 40-90 % 감소시키는 대신 15-35 %의 개발 시간을 추가한다는 것을 보여줍니다.

이 기사는 전체 종이를 의미 (PDF)를 - Nachiappan Nagappan, E. 마이클 막시, Thirumalesh 바트, 그리고 로리 윌리엄스. “테스트 중심 개발을 통한 품질 개선 현실화 : 4 개의 산업 팀의 결과 및 경험”. ESE 2008 .

_{요약TDD (Test-driven development)는 수십 년 동안 산발적으로 사용 된 소프트웨어 개발 사례로, 소프트웨어 엔지니어는 실패한 단위 테스트 작성과 구현 코드 작성 사이에서 1 분마다 순환하여 해당 테스트를 통과합니다. 테스트 중심 개발은 최근 민첩한 소프트웨어 개발 방법론의 중요한 구현 사례로 다시 등장했습니다. 그러나 산업적 상황에서이 관행의 유용성을지지하거나 반박하는 경험적 증거는 거의 없다. 사례 연구는 Microsoft의 3 개 개발 팀과 TDD를 채택한 IBM의 한 개발 팀에서 수행되었습니다. 사례 연구의 결과는 4 가지 제품의 시험판 결함 밀도가 TDD 사례를 사용하지 않은 유사한 프로젝트에 비해 40 %와 90 % 사이에서 감소한 것으로 나타났습니다. 주관적으로}

_{전체 논문은 짧게는 관련 경험 TDD에 대한 연구와 높은 수준의 결과 (섹션 요약 3 개 관련 작품 조지 윌리엄스 2003 뮐러와 Hagner (2002), Erdogmus 등을 포함하여). (2005), Müller and Tichy (2001), Janzen and Seiedian (2006).}

몇 가지 사항에 대한 테스트를 작성하면 약간의 이점이 있지만 매우 적습니다. 테스트를 먼저 작성한다는 아이디어가 마음에 들지만 테스트를 디버깅하여 실제 코드를 디버깅하는 것보다 실제로 의미하는 바를 말하기 위해 더 많은 시간을 소비합니다.

나는 지난 3 년간 TDD를 해왔으며, 내 경험은 정반대입니다. 단위 테스트를 작성하지 않은 경우 코드 디버깅에 필요한 단위 테스트 작성 시간이 줄어 듭니다.

TDD뿐만 아니라 외부에서 작업합니다. 즉, 맨 위 / gui 레이어 TDD를 먼저 구현합니다. 최상위 계층을 구현하면 기능에 필요한 모든 코드가 구현 될 때까지 TDD 등을 사용하여 개발하는 시스템의 다음 계층에 대한 요구 사항이 정의됩니다. 종종 이와 같은 기능을 구현 한 후 실제 시스템에서 기능을 연기 테스트하면 처음으로 작동한다는 것을 경험합니다. 항상 그렇지는 않지만 종종.

실제 시스템의 기능을 연기 테스트하는 데 몇 단위 테스트를 수행하는 것보다 시간이 오래 걸리기 때문에 엄청난 시간을 절약 할 수 있습니다. 단위 테스트를 전혀 작성하지 않는 기능을 구현하지 않는 것보다 TDD를 사용하여 기능을 구현하는 것이 실제로 더 빠릅니다.

그러나 단위 테스트 작성은 다른 프로그래밍 기술과 마찬가지로 학습하고 숙달해야하는 기술입니다. TDD를 시작했을 때 저는 12 년 동안 프로그래밍에 대한 전문적인 경험을 쌓았으며 매우 뛰어난 프로그래머였습니다. 시스템 코드에 대해 큰 테스트 스위트를 작성하는 것이 간단하다고 생각했습니다. 그러나 테스트 코드의 양이 증가하고 시스템의 다른 부분이 변경되고 기존 테스트를 수정해야했기 때문에 단위 테스트 구성 및 작성 자체가 배우고 숙달해야 할 기술이라는 것을 알게되었습니다. 또한 모든 코드가 똑같이 테스트 가능한 것은 아닙니다. 효율적으로 테스트 할 수 있으려면 시스템 코드가 느슨하게 연결되어 있어야합니다. 실제로 TDD를 학습하면 시스템 코드를 느슨하게 결합하는 데 도움이되었습니다.

그러나 TDD 작업의 현재 효율성은 단위 테스트 작성 방법을 마스터하는 것뿐만 아니라 시스템이 구현되는 기술을 마스터하는 것 (이 경우 C #)입니다.

새로운 기술을 배우는 동안 TDD를 수행하는 것은 어려울 수 있습니다. 예를 들어, 약간의 iPhone 프로그래밍을 해왔지만 언어, 객관적 c 또는 마스터를하지 않기 때문에 상당한 단위 테스트를 작성하지 않습니다. 도서관. 따라서 단위 테스트를 구성하는 방법을 알지 못하며 시스템 코드를 구성하여 테스트 할 수있는 방법은 적습니다.

그러나 실제 프로젝트에서 얼마나 잘 작동합니까?

지난 2 년 동안 작업 해 온 프로젝트에서 코드를 단위 테스트로 충분히 다루어야한다는 요구 사항이 있지만 테스트를 먼저 작성하는 팀은 유일합니다. 그러나 대규모 테스트 스위트는 시스템을 리팩터링 할 수 있다는 확신을 주었으며 테스트 스위트가 통과하면 시스템이 올바르게 작동 할 것이라고 확신합니다.

그러나 불행히도 많은 테스트가 시스템 코드 이후에 작성되기 때문에 테스트 자체의 상당수가 잘못되었습니다. 즉, 실제로 테스트 대상을 테스트하지 않습니다. 이 imho는 피할 수 없습니다. 코드를 작성할 때마다 의도 한대로 코드가 작동하지 않을 가능성이 있습니다 (예 : 버그). 테스트 코드도 마찬가지입니다. 따라서 테스트해야 할 코드가 의도 한대로 작동하지 않더라도 통과하는 테스트를 작성할 가능성이 있습니다.

먼저 테스트를 작성하여 테스트 실패를 확인하는 것뿐만 아니라 시스템 코드를 구현하기 전에 예상 한 오류 메시지와 함께 테스트가 실패하는지 확인하면 단위 테스트 코드의 버그 위험이 심각하게 줄어 듭니다.

요약하자면, TDD의 기술을 습득하면 내 경험상 장기적으로 시간을 절약 할 수있을뿐 아니라 시간을 앞당길 수 있습니다. 그러나 숙련 된 프로그래머라도 TDD 기술을 익히려면 시간이 걸립니다. 또한 다양한 기술을 갖춘 개발자 팀이 TDD 기술을 습득하는 데 시간이 더 걸립니다.

우리는 막대한 이익을 얻었습니다.

Google은 1 단계 판매자로서 매년 6 백만 건 이상의 결제 거래를 처리합니다.

당사의 결제 게이트웨이 시스템에는 수천 개의 단위 및 통합 테스트가 있습니다. 이 테스트는 지불 처리 능력에 대한 확신을줍니다. 자동차 브레이크가 작동한다고 확신하고 싶습니까? 우리는 지불을 처리 할 수 ​​없기 때문에 비즈니스를 잃지 않을 것을 확신하고 싶습니다.

코드 적용 범위는 그러한 확신을줍니다. 물론 그것만으로는 충분하지 않지만 아주 좋은 시작입니다.

대부분의 결제 게이트웨이 시스템은 TDD를 사용하여 작성되었습니다. 일부 측면은 테스트하기가 다소 어려웠으므로 일부 코드 적용 범위를 희생하여 모서리를 줄이기로 결정했습니다. 우리는 다시 돌아와서 이러한 문제를 해결할 것입니다.

개인적으로 테스트를 작성하기 전에 논리를 작성하기가 어렵다는 것을 알게되었습니다. 그렇게 말하면서 TDD 방식으로 생각하기 시작하는 데 약간의 시간이 걸렸습니다.

비자 PCI 참조 : http://usa.visa.com/merchants/risk_management/cisp_merchants.html

테스트는 종종 일부 사람들에 의해 너무 많은 일을하는 방법으로 간주 될 수 있지만, 어떤 경우에는 문제의 가치가 있다고 생각합니다.

나는 약 3 개월 동안 학교를위한 Killer Sudoku Solver를 개발해 왔으며, 많은 "전략"을 사용하여 가능성과 해결책을 제거합니다. 사실, 가능성의 오류는 치명적일 수 있으며 스도쿠를 해결하는 데 문제가 발생할 수 있습니다. 왜냐하면 일부 가능성이 제거되면 더 이상 시도하지 않고 해결책이라면 프로그램을 해결할 수 없기 때문입니다. 더 이상 그리드.

그러나 실제로 수동으로 테스트하기는 어렵습니다. 그리드가 있다는 것을 의미합니다. 실제 사례에서 어떤 전략을 수행하고 있는지 알 수 있지만 전략이 적용될 때마다 데이터가 너무 많기 때문에 모든 시간을 확인할 수는 없습니다.

특정 그리드에 적용되는 전략은 매우 "임의"입니다. 즉, 특정 그리드에 모두를 사용하지는 않습니다.

그래서 나는 각 전략에 대한 테스트를 작성하여 간단한 상황을 사용하여 모든 셀의 결과를 확인했습니다 (예 : 두 셀 만 이미 가능성을 제거했습니다). 불행히도 해결할 수없는 그리드가있을 때 하루에 몇 시간을 절약했습니다. 문제가 어디 있는지 이미 알고 있었기 때문입니다.

TDD의 장점은 실제 코드를 작성하기 전에 코드 를 호출 하는 방법을 알아내는 것 입니다.

즉, TDD는 API 설계에 도움이됩니다.

내 경험상 이것은 더 나은 API를 가져오고 더 나은 코드를 제공합니다.

편집 : 내가 쓴 것처럼 이것은 "내 경험", 즉 "실제 프로젝트"를 작성할 때 발생했지만 불행히도 이것은 닫힌 소스 코드 기반으로 세계를 볼 수 없습니다. 의견에서 이것이 실제로 요구되는 것이며 단지 그러한 프로젝트의 존재를 확인하는 것이 아니라는 것을 이해할 수 있습니다.

또한 개인 경험에서 다시 한 번 요구 사항이 변경되는 경향이 있기 때문에 유지 관리 모드로 전환하면 실제 이점이 나타납니다. 더 깨끗한 API를 사용하면 테스트 코드에서 새로운 요구 사항이나 변경된 요구 사항을 표현하기가 훨씬 쉬워졌으며 모든 테스트 를 통해 향후 관리자에게 코드 호출 방법 및 예상되는 내용을 매우 쉽게 확인할 수 있습니다.

테스트 케이스는 스펙의 버전을 실행 중이므로 API를 호출하는 방법을 매우 쉽게 볼 수 있습니다. 이것은 아마도 지금까지 본 것 중 가장 유용한 단일 형식의 "HOW" 문서 ( JavaDoc과 같은 "WHY" 문서와 비교 ) 일 것입니다. 그렇지 않으면 테스트가 실패 할 것입니다.

최근에는 응용 프로그램의 작동 방식에 영향을주는 매우 큰 옵션 세트를 사용하여 스크립트 가능한 ftp 클라이언트를 유지 관리해야했습니다. TDD는 최근 새로운 기능을 위해 도입되었으며 대규모 테스트 스위트를 사용하면 사용 된 기능이 여전히 예상대로 작동 함을 확신하면서 핫픽스를 수행 할 수 있습니다. 다시 말해,이 전환은 매우 빨리 성과를 거두었습니다.

테스트에 대한 특정 접근 방식의 가치는 개발중인 시스템의 미션 크리티컬 방식과 다른 미션 크리티컬 시스템의 의존도에 따라 다릅니다. 귀하의 웹 사이트에 대한 간단한 방명록 스크립트는 미션 크리티컬 한 것으로 간주 될 수 없지만 데이터베이스에 대한 필터링되지 않은 입력을 허용하고 해당 사이트가 중요한 서비스를 제공하는 버그로 인해 웹 사이트가 실행되는 웹 사이트가 잠재적으로 더 많이 손상 될 수 있습니다. 방명록 스크립트를 철저히 테스트하는 데 중요합니다. 프레임 워크 / 라이브러리 코드도 마찬가지입니다. 버그가있는 프레임 워크를 개발하면 해당 프레임 워크 기능을 사용하는 모든 응용 프로그램에도 동일한 버그가 있습니다.

테스트 중심 개발은 테스트와 관련하여 추가적인 안전성을 제공합니다. 테스트하려는 코드와 함께 또는 테스트 후에 테스트를 작성하면 테스트가 잘못 될 위험이 있습니다. 모든 테스트를 먼저 작성하면 코드가 내부적으로 작동하는 방식이 테스트 작성에 영향을 줄 수 없으므로 특정 오류 출력이 정확하다고 생각하는 테스트를 실수로 작성할 가능성이 줄어 듭니다.

테스트 주도 개발은 개발자가 더 많은 작업을 수행하고 싶지 않기 때문에 테스트하기 쉬운 코드를 작성하도록 권장합니다! 테스트하기 쉬운 코드는 이해, 재사용 및 유지 관리가 쉬운 코드 인 경향이 있습니다.

그리고 유지 관리는 TDD의 보상을 실제로 얻을 수있는 곳입니다. 소프트웨어에 소비되는 프로그래밍 노력의 대부분은 유지 관리와 관련이 있습니다. 즉, 라이브 코드를 변경하여 새로운 기능을 제공하거나 버그를 수정하거나 새로운 상황에 맞게 조정할 수 있습니다. 이러한 변경을 수행 할 때 변경 한 내용에 원하는 효과가 있는지 확인하고 더 중요한 것은 예기치 않은 영향을주지 않는 것입니다. 코드에 대한 전체 테스트 스위트가 있다면 변경 사항이 다른 내용을 위반하지 않는지 쉽게 확인할 수 있으며 변경 사항이 다른 부분을 위반하면 이유를 신속하게 찾을 수 있습니다. 혜택은 장기적입니다.

당신은 당신의 질문에 다음과 같이 말했습니다.

몇 가지 사항에 대한 테스트를 작성하면 약간의 이점이 있지만 매우 적습니다. 테스트를 먼저 작성한다는 아이디어가 마음에 들지만 테스트를 디버깅하여 실제 코드를 디버깅하는 것보다 실제로 의미하는 바를 말하기 위해 더 많은 시간을 소비합니다. 테스트 코드가 테스트하는 코드보다 훨씬 더 복잡하기 때문일 수 있습니다. 사용 가능한 도구 (이 경우 rspec)를 사용하지 않았 으면 좋겠습니다.

이것은 당신이 테스트를받지 못하고 있다고 제안하는 것 같습니다. 단위 테스트는 일련의 메소드 호출과 매우 간단해야하며 예상 결과와 실제 결과를 비교하기위한 주장이 뒤 따릅니다. 테스트의 버그가 재앙이 될 수 있기 때문에 간단합니다. 루프, 분기 또는 다른 프로그램이 제어를 테스트에 도입하면 테스트에 버그가 발생할 가능성이 높아집니다. 테스트 디버깅에 많은 시간을 소비하는 경우 테스트가 지나치게 복잡하다는 것을 나타내며 단순화해야합니다.

테스트를 단순화 할 수없는 경우 그 사실만으로 테스트중인 코드에 문제가 있음을 암시합니다. 예를 들어 클래스에 긴 메소드, if / elseif / else 또는 switch 문이 많은 메소드 또는 클래스의 현재 상태에 따라 복잡한 상호 작용이있는 많은 메소드가있는 경우 테스트는 매우 복잡해야합니다. 전체 코드 범위를 제공하고 모든 이벤트를 테스트합니다. 클래스에 다른 클래스에 대한 하드 코딩 된 종속성이있는 경우 코드를 효과적으로 테스트하기 위해 점프해야하는 후프 수가 다시 증가합니다.

실행 경로가 적은 짧은 메소드를 사용하여 클래스를 작고 집중적으로 유지하고 내부 상태를 제거하려고하면 테스트를 단순화 할 수 있습니다. 그리고 이것은 문제의 핵심입니다. 좋은 코드는 본질적으로 테스트하기 쉽습니다. 코드를 테스트하기가 쉽지 않으면 문제가있을 수 있습니다.

단위 테스트를 작성하는 것은 장기적으로 도움이되며,이를 피하는 것은 나중에 문제를 저장하는 것입니다. 기술 부채 개념에 익숙하지 않을 수도 있지만 재정 부채와 매우 유사합니다. 테스트 작성, 코드 주석 달기, 하드 코딩 된 종속성 작성 등은 부채로가는 방식입니다. 코너를 일찍 자르면 시간을 "빌리 게"되며 마감 시한을 맞추는 데 도움이 될 수 있지만 프로젝트에서 더 빨리 절약 할 수있는 시간은 대출입니다. 매일 코드를 정리하지 않고 적절하게 주석을 달거나 테스트 스위트를 빌드하면 비용이 많이 듭니다. 더 오래 갈수록 더 많은 관심이 축적됩니다. 결국, 코드가 의도하지 않은 결과를 유발하지 않으면 서 변경할 수없는 복잡한 문제가 된 것을 알게 될 것입니다.

단위 테스트를 조기에 작성하여 "기술적 신용"형태로 최신 상태로 유지하는 것을 생각할 수 있습니다. 좋은 연습을 따르는 데 프로젝트에서 일찍 돈을 써서 은행에 시간을 투자하고 있습니다. 나중에 프로젝트의 유지 보수 단계에 도달하면이 예측에 관심을 가지게됩니다. 변경하고 싶을 때 변경의 정확성을 쉽게 확인할 수 있으며 원치 않는 부작용이 없는지 신속하게 확인할 수 있습니다. 버그가 나타나면 버그를 연습하는 새로운 단위 테스트를 추가 한 다음 코드에서 버그를 수정하십시오. 다음에 단위 테스트를 실행하면 버그가 수정되었고 다른 문제가 발생하지 않았 음을 확인할 수 있습니다. 또한 "회귀"를 피할 수 있습니다.

TL : DR-그렇습니다. 그들은 실제적인 도움이지만 투자입니다. 이점은 나중에 분명해집니다.

직장에서 TDD를 자주 사용하고 있습니다. 내 경험은 TDD의 정당화 자체 추가 시간이나 노력을 지불하지 않기 때문에, 당신은 저장 을.

• TDD를 사용하기 때문에 디버깅 등에 훨씬 적은 시간을 소비합니다. 테스트가 통과하지 않는 한 생산적인 코드를 고려하지 않기 때문에 처음부터 작동합니다.

• QA는 버그를 훨씬 적게보고하므로 릴리스 후 코드를 복구하는 데 드는 비용을 절약합니다. TDD를 사용하면 테스트없이 코드를 작성할 수 없으므로 코드 적용 범위가 훨씬 향상됩니다.

• 전체 응용 프로그램 서버를 시작할 필요가 없기 때문에 (생산적인) 코드를 훨씬 더 빠르고 빠르게 실행할 수 있습니다. 단위 테스트를 시작하는 것이 훨씬 빠릅니다. 물론 생산적인 코드를 시험 해보고 싶을 때 테스트가 이미 실행 가능한 경우에만 이점이 있습니다. 테스트가 완료되면이 혜택이 사라집니다.

• 수동 테스트는 훨씬 적습니다. TDD를 연습하지 않는 동료들은 새 코드가 실행되는 시점에 도달 할 때까지 애플리케이션을 클릭하는 데 많은 시간을 소비합니다. 버전 관리에 전념하기 직전에 한 번만 수동으로 테스트합니다.

• 디버거를 사용하더라도 전체 응용 프로그램보다 테스트 실행을 디버깅하는 것이 훨씬 빠릅니다.

단위 테스트를 회귀 테스트라고 생각할 수 있습니다. 즉 자신의 목적 중 하나이지만 도구로 이해 를위한 개발하는 것은 그들이 훨씬 더 가치가 있습니다.

고객 승인 테스터 또는 (허용되지 않은) 프로덕션 사용자가 버그를 발견하면 또 다른 이점 (응답 한 다른 사람들이 언급 한 것 외에도)이 시작됩니다. 버그 보고서를 결함이있는 것으로 보이는 클래스에 대한 TDD 스타일 테스트로 바꾸십시오. 실패를 조심하십시오. 고치세요 통과하는 것을보십시오. 그런 다음 버그를 수정했다는 것을 알고 있습니다. 이 기술로 시간이 절약되었습니다.

글쎄, 나는 동료 개발자보다 두 배 빠르며 개인적으로 이익을 얻고 TDD를하지 않기 때문에 버그를 절반 이하로 씁니다. 아마도 나보다 나은 사람 일 것입니다 ... 나는 적어도 2 배나 더 뛰어납니다.

나는 바로 거기에 도착하지 않았다. 커프에서 코드를 작성하고 하네스없이 잘 작성했습니다. 이 여분의 쓰레기를 모두 쓰는 것은 큰 낭비처럼 보입니다. 그러나 다음을 포함하여 여러 가지 작업을 수행합니다.

• 디커플링 및 재사용을 위해 설계된 디자인을 강요합니다 (모든 것이 단위 테스트에서 재사용되어야 함).
• 작은 청크와 모듈로 코드를 개발할 수있는 플랫폼을 제공하므로 간단한 "컴파일 및 입력도 수행"종류의 테스트를 실행하기 전에 모든 것을 파악하고 완료 할 필요가 없습니다.
• 사람들이 기능 변경을 요구할 때 변경을 수행 할 수있는 빠른 테스트 플랫폼을 제공합니다.

이 마지막 비트의 예는 제가 현재 진행하고있는 프로젝트로, 리드가 갑자기 거의 0 가지 이유로 사용한 통신 프로토콜을 완전히 다시 작성하기로 결정한 프로젝트입니다. 나는 이미 다른 모든 것에서 그것을 분리하고 마지막으로 묶을 때까지 완전히 독립적으로 작업하고 테스트 단계를 통합함으로써 2 시간 만에 그 변화에 대응할 수있었습니다. 내 동료의 대부분은 아마도 코드가 분리되지 않고 여기저기서 어디에서나 ... 모든 것을 컴파일 ... 통합 테스트 ... 반복, 반복하기 때문에 하루 이상 머물렀을 것입니다. ... 훨씬 더 오래 걸리고 그다지 안정적이지 않습니다.

대답은 '예'입니다. 우리 회사에서는 20 년 이상 C ++ 애플리케이션을 개발해 왔습니다. 작년에 우리는 일부 새로운 모듈에서 TDD를 시작했으며 결함률이 크게 감소했습니다. 우리는 너무 좋아서 무언가를 변경할 때마다 레거시 코드에 테스트를 추가하기까지했습니다.

또한, 전체 모듈은 버그를 보여주지 않고 생산을 진행하면서 처음부터 끝까지 완성되었습니다 (중요한 모듈이기도 함). 일반적으로 그렇지 않은 것은 모듈이 "완료"되고 베타 테스트에서 버그 수정에 대해 4-5 회만 반환하기 때문에 개발 속도가 평소보다 빨랐습니다. 상당한 개선이었고 개발자들은 새로운 프로세스에 더 기뻐했습니다.

나는 많은 Rails TDD를 수행하지 않았지만 C ++, C #, Java 및 Python에서 많은 작업을 수행했습니다. 나는 그것이 확실히 작동한다고 말할 수 있습니다. 내 생각 엔 충분히 자신감이 없기 때문에 테스트 이름에 대해 많은 시간을 소비하고있는 것입니다. 먼저 테스트를 작성하되 창의력을 발휘하십시오 ...

TDD를 중단하고 나면 "어떻게이 테스트의 이름을 지정합니까 ... argh!"에 대해 조금 덜 신경 쓰기 시작하고 이미 작성하여 리팩토링하고 이미 작성된 것입니다. 현재 상황에 맞는 테스트.

팁을위한 시간

팁 # 1

가장 도움이 될만한 팁은 크게 걱정하지 않는 것입니다. TDD의 가장 아름다운 점 중 하나는 이미 작성되어 작동중인 것을 변경하는 데 용기를 준다는 것입니다. 그리고 여기에는 테스트가 포함됩니다.

팁 # 2

간단한 "canCreate"테스트로 새로운 클래스 테스트를 시작하십시오. "Ok, 지금이 클래스에서 작업 중입니다 ..."와 같이 올바른 방향으로 마음을 정하십시오.

그런 다음 테스트를 한 번에 하나씩 만 더 추가하고 생성 한 각 테스트가 해당 시점에서 생각 나는 다음으로 간단한 경우인지 확인하십시오 (30 초 이하로 생각한 후 시간 초과) 그 시점에서 최고로).

그리고 기억

기존 테스트를 리팩토링하거나 쓸모 없거나 중복 된 테스트를 제거하는 것에 대해 걱정하지 마십시오. 많은 사람들이 이것을 알지 못하지만 TDD에서는 실제로 1의 가격으로 2 개의 안전망을 얻습니다. 테스트는 생산 코드 변경을위한 안전망이지만 생산 코드는 테스트를 리팩토링하기위한 안전망이기도합니다. 관계는 상호입니다. 실제로 타이트한 커플 링의 좋은 경우입니다.

다른 기회를주세요. Clean Code Casts 특히 TDD에 관한 것들을 시청하는 것이 좋습니다 .

실제 사소한 예 :

데이터 구조 변환 함수를 작성해야했습니다. 입력은 데이터 구조 (실제로 트리와 매우 유사한 중첩 데이터 구조)이며 출력은 비슷한 데이터 구조입니다. 나는 내 마음 속에 실제 변화를 시각화 할 수 없었다. 어쨌든 TDD의 주요 이점 중 하나는 진행 방법을 모르는 경우 베이비 스텝을 시행하는 것입니다 (Kent Becks "TDD by Example"참조). 나는 이것이 어디로 가고 있는지 알지 못했기 때문에 빈 입력이나 사소한 입력과 같은 간단한 기본 사례로 시작하여 내가 모두 다루었을 때까지 더 복잡한 사례까지 진행했습니다. 결국 나는 작동하는 알고리즘과 그것을 증명하는 테스트를 받았습니다. 테스트 결과 내 구현이 현재 작동하고 있음을 증명할뿐만 아니라 나중에 나사를 조이지 않아도됩니다.

나는 대부분의 개발자가 응용 프로그램의 생산성을 높이고 결함을 줄이는 데 도움이되는 단일 크기의 제안이 있다고 믿지 않기 때문에 일반적인 조언을 맹목적으로 따르는 아이디어를 좋아하지 않습니다. 내 경험에 따르면 품질에 대해 걱정할수록 제공되는 새로운 기능의 양이 더 많이 손실됩니다. 따라서 품질 대 배송 가능성에 제공하려는 중요성 수준은 실제로 제품 및 현재 전략에 달려 있으며, 아마도 당분간보다 중요한 것을 전략적으로 결정할 사람이 될 것입니다. 견고성 또는 배송 가능성.

이 결정조차도 검은 색이나 흰색이 아닙니다. 대부분의 경우 응용 프로그램의 일부는 견고해야하지만 다른 일부는 그럴 필요가 없습니다. 높은 품질을 가져야하는 부품을 식별 한 후에는 해당 부품에 대해 높은 품질을 보장하기 위해 테스트 관점에서 해당 부품에 집중해야합니다.

지금까지 내가 말한 모든 것은 구현 전에 테스트를 작성한다는 의미에서 TDD와는 아무런 관련이 없지만 테스트를 수행 한 것과 테스트를 먼저 작성하는 것의 이점을 분리하는 것이 중요하다고 생각합니다.

테스트 자체 (TDD) 자체의 이점을 이해하면 테스트에서 다루고 싶은 코드에 대한 테스트 전략을 논의 할 수 있습니다. 어떤 사람들은 나중에 테스트를 작성하면 테스트에서 일부 조건을 놓치게 될 것이라고 주장하지만, 그것이 당신에게 적용되는지 여부를 평가할 수있는 사람이라고 생각합니다. 그것은 나에게 적용되지 않습니다.

그래서, 그것이 나를 위해 작동하는 방법입니다. 기본적으로 테스트를 작성하는 두 가지 상황이 있습니다. 품질 만 향상 시키거나 일부 기능의 개발 속도를 높일 수도 있습니다. 따라서 테스트를 작성하는 상황은 백 로그에 새로운 기능이없는 경우에 응용 프로그램의 성능을 향상 시키거나 코드 기반을 단순화하거나 테스트 스위트를 향상시킬 수 있습니다. 또 다른 상황은 버그가 실제 클라이언트에 충분히 큰 영향을 미치는 견고한 작업 코드가 필요하다는 것입니다. 또 다른 하나는 복잡한 코드를 테스트 할 때 쉽게 깨질 수있는 복잡한 코드를 테스트하는 것입니다. 예를 들어, 내 코드 기반에는 많은 사용 사례를 처리하는 QueryBuilder 클래스가 있으며 버그를 수정하거나 새로운 기능을 추가하는 동안 일부를 중단하기가 쉽습니다.

마지막으로, 테스트를 작성하는 것이 먼저 테스트를 작성하지 않고 기능을 더 빨리 작성할 수있는 경우가 있습니다. 이 QueryBuilder도이 규칙이 적용되는 경우 였지만 TDD가 최고의 경로라는 의미는 아닙니다. 개발 속도를 돕는 TDD의 또 다른 예는 예를 들어 Excel 생성을 테스트하는 것입니다. 반면 실제 응용 프로그램에서는 생성의 특정 조건을 테스트 할 때마다 여러 단계를 수행해야 할 수도 있습니다. 또는 기능을 테스트하기 위해 일부 레코드를 작성해야하며 코드를 수동으로 테스트 한 후 수동으로 삭제하기 어렵거나 불가능합니다.

따라서 일부 개발 코드를 프로그래밍 방식으로 (테스트를 통해) 실행하는 단계를 쉽게 재현 할 수 있다면 계속 진행하십시오. 그러나 테스트를 작성하는 것이 더 복잡하고 수동으로 테스트하는 경우 품질에 중점을 둘 시간인지 또는 백 로그에 많은 요청이 있고 회사의 누군가가 더 잘 알고 귀하에게 알려 줄지 결정해야합니다 현재의 필요와 회사 전략에 따라 어디에 집중해야하는지 파악하십시오.

이상적인 세계에서는 모든 코드가 테스트되지만 트레이드 오프가 없다고 가정 할 수 없으며 TDD가 항상 최선의 길이라고 가정합니다. 모든 모범 사례와 마찬가지로 항상 자신에게 더 나은 것이 아니라 일하는 회사에 가장 적합한 것에 집중해야합니다. 자영업자가되면 TDD가 최선의 길이라고 생각되면 언제든지 TDD를 수행하기로 결정할 수 있습니다. 회사에서 모든 코드를 테스트해야한다고 생각하면 작성한 모든 코드에 대한 테스트를 작성해야합니다. 그러나 대부분의 경우 결정을 내리기 전에 큰 그림을보고 절충점을 이해해야합니다. 죄송합니다. 그러나 이것은 정확한 과학이 아니며 매번 따라야 할 쉬운 (또는 어려운) 단일 크기의 모든 대답은 없습니다.

디자인 패턴과 동일합니다. 그들이 어떻게 작동하고 왜 만들어 졌는지, 어떤 종류의 문제를 해결하고 그들의 단점도 이해합니다. 제안 된 솔루션을 기억하는 것보다 추론이 훨씬 중요하다는 것을 이해하십시오. 오늘날 고가의 작업은 다른 기술을 통해 내일 쉽게 달성 할 수 있습니다. 잘 정립 된 솔루션에 대한 전제가 더 이상 유효하지 않은 경우 솔루션이 더 이상 사용하기에 가장 적합하지 않습니다. 요구 사항, 사용 가능한 기술 또는 회사 전략이 변경되면 항상 도구 상자를 재평가해야하며, 그러한 경우에는 각 경로를 최상의 옵션으로 부여하는 대신 처음부터 선택한 이유를 이해해야합니다.