테스트 주도 개발의 단점?[닫은]

https://stackoverflow.com/questions/64333

09-06-2019
|

문제

테스트 중심 설계를 채택하면 무엇을 잃게 됩니까?

부정적인 것만 나열하십시오.부정적인 형태로 혜택을 기재하지 마십시오.

해결책

몇 가지 단점(그리고 이점이 없다고 주장하는 것이 아닙니다. 특히 프로젝트의 기초를 작성할 때 마지막에 많은 시간을 절약할 수 있습니다):

큰 시간 투자. 간단한 경우에는 실제 구현의 약 20%를 잃게 되지만, 복잡한 경우에는 훨씬 더 많은 것을 잃게 됩니다.
추가적인 복잡성. 복잡한 경우에는 테스트 사례를 계산하기가 더 어렵습니다. 그런 경우에는 가장 간단한 사례의 단위 테스트 대신 디버그 버전/테스트 실행에서 병렬로 실행되는 자동 참조 코드를 사용해 보는 것이 좋습니다.
디자인 영향. 때때로 디자인이 처음에는 명확하지 않고 진행하면서 발전합니다. 이로 인해 테스트를 다시 실행해야 하게 되어 큰 시간 손실이 발생하게 됩니다.이 경우에는 디자인을 어느 정도 이해할 때까지 단위 테스트를 연기하는 것이 좋습니다.
지속적인 조정. 데이터 구조 및 블랙박스 알고리즘의 경우 단위 테스트는 완벽할 수 있지만 변경, 조정 또는 미세 조정되는 경향이 있는 알고리즘의 경우 이는 정당화되지 않는다고 주장할 수 있는 막대한 시간 투자를 초래할 수 있습니다.따라서 실제로 시스템에 적합하다고 생각하고 디자인을 TDD에 맞추도록 강요하지 않을 때 사용하십시오.

다른 팁

"실제" TDD를 수행하려는 경우(읽기:먼저 빨간색, 녹색, 리팩터링 단계로 테스트한 다음 통합 포인트를 테스트하려면 모의/스텁을 사용하기 시작해야 합니다.

모의 객체를 사용하기 시작하면 잠시 후 DI(종속성 주입) 및 IoC(제어 반전) 컨테이너를 사용하고 싶을 것입니다.그렇게 하려면 모든 것에 인터페이스를 사용해야 합니다(그 자체에는 많은 함정이 있습니다).

결국에는 "평범한 옛날 방식"으로 작성하는 것보다 훨씬 더 많은 코드를 작성해야 합니다.고객 클래스뿐만 아니라 인터페이스, 모의 클래스, 일부 IoC 구성 및 몇 가지 테스트도 작성해야 합니다.

그리고 테스트 코드도 유지 관리되어야 한다는 점을 기억하세요.테스트는 다른 모든 것과 마찬가지로 읽기 쉬워야 하며 좋은 코드를 작성하는 데는 시간이 걸립니다.

많은 개발자들은 이러한 모든 작업을 "올바른 방법"으로 수행하는 방법을 잘 이해하지 못합니다.그러나 모두가 TDD가 소프트웨어를 개발하는 유일한 진정한 방법이라고 말하기 때문에 그들은 최선을 다할 뿐입니다.

생각보다 훨씬 어렵습니다.종종 TDD로 수행된 프로젝트는 누구도 실제로 이해하지 못하는 많은 코드로 끝나게 됩니다.단위 테스트는 잘못된 것을 잘못된 방식으로 테스트하는 경우가 많습니다.그리고 누구도 좋은 테스트가 어떤 모습이어야 하는지에 대해 동의하지 않습니다. 소위 전문가라고 불리는 사람도 마찬가지입니다.

이러한 모든 테스트로 인해 시스템 동작을 "변경"(리팩토링과 반대)하는 것이 훨씬 더 어려워지고 간단한 변경은 너무 어렵고 시간이 많이 걸립니다.

TDD 문헌을 읽으면 항상 매우 좋은 예가 있지만 실제 애플리케이션에서는 사용자 인터페이스와 데이터베이스가 필요한 경우가 많습니다.이것이 바로 TDD가 정말 어려워지는 부분이며 대부분의 소스는 좋은 답변을 제공하지 않습니다.그리고 만약 그렇다면 항상 더 많은 추상화가 필요합니다.모의 객체, 인터페이스 프로그래밍, MVC/MVP 패턴 등에도 많은 지식이 필요하며...더 많은 코드를 작성해야 합니다.

그러니 조심해...열정적인 팀이 없고, 좋은 테스트를 작성하는 방법을 알고 좋은 아키텍처에 대한 몇 가지 사항도 알고 있는 숙련된 개발자가 한 명도 없다면 TDD로 가기 전에 두 번 생각해야 합니다.

많은 수의 테스트가 있는 지점에 도달하면 시스템을 변경하면 변경으로 인해 무효화되는 테스트에 따라 일부 또는 전체 테스트를 다시 작성해야 할 수도 있습니다.이로 인해 비교적 빠른 수정이 매우 시간 소모적인 수정으로 바뀔 수 있습니다.

또한 실제로 좋은 디자인 원칙보다는 TDD를 기반으로 디자인 결정을 내릴 수도 있습니다.TDD가 요구하는 방식을 테스트하는 것이 불가능한 매우 간단하고 쉬운 솔루션이 있었을 수도 있지만 이제는 실제로 실수하기 쉬운 훨씬 더 복잡한 시스템이 있습니다.

제 생각에 가장 큰 문제는 "시작"하는 데 걸리는 엄청난 시간 손실입니다.나는 아직도 TDD 여정의 시작 단계에 있습니다. 블로그 관심이 있으시면 내 테스트 모험을 업데이트하기 위해) 문자 그대로 지출했습니다. 시간 시작하기.

두뇌를 "테스트 모드"로 전환하는 데는 오랜 시간이 걸리며 "테스트 가능한 코드"를 작성하는 것 자체가 기술입니다.

TBH, 정중히 동의하지 않습니다. 제이슨 코헨의 코멘트 비공개 메서드를 공개하는 것에 대한 내용은 그게 아닙니다. 나는 새로운 작업 방식으로 이전보다 더 이상 공개 방법을 만들지 않았습니다..그러나 여기에는 아키텍처 변경이 포함되며 코드 모듈을 "핫 플러그"하여 다른 모든 것을 더 쉽게 테스트할 수 있습니다.당신은해야 ~ 아니다 이를 위해 코드 내부에 더 쉽게 접근할 수 있도록 만들어야 합니다.그렇지 않으면 우리는 모든 것이 공개된 원점으로 돌아가게 됩니다. 여기서 캡슐화는 어디에 있습니까?

따라서 (IMO) 간단히 말해서:

생각하는 데 걸린 시간(예:실제로 grok'ing 테스트).
테스트 가능한 코드를 작성하는 방법을 아는 데 필요한 새로운 지식입니다.
코드를 테스트 가능하게 만드는 데 필요한 아키텍처 변경 사항을 이해합니다.
우리의 영광스러운 프로그래밍 기술에 필요한 다른 모든 기술을 향상시키려고 노력하면서 "TDD-Coder" 기술을 향상시키세요 :)
프로덕션 코드를 망치지 않고 테스트 코드를 포함하도록 코드 베이스를 구성합니다.

추신:긍정적인 내용에 대한 링크를 원하시면 제가 이에 대해 몇 가지 질문과 답변을 드렸습니다. 내 내용을 확인하세요. 프로필.

제가 테스트 주도 개발을 연습해온 몇 년 동안 가장 큰 단점은 다음과 같습니다.

경영진에게 판매

TDD는 쌍으로 수행하는 것이 가장 좋습니다.우선, 구현을 작성하고 싶은 충동을 억제하기가 어렵습니다. 알다 작성하는 방법 다른 경우라면 성명.그러나 당신이 그에게 일을 계속하게 하기 때문에 한 쌍은 당신도 일을 계속하게 할 것입니다.안타깝게도 많은 회사/관리자는 이것이 자원을 잘 활용하는 것이라고 생각하지 않습니다.동시에 수행해야 하는 두 가지 기능이 있는데 왜 두 사람이 하나의 기능을 작성하도록 비용을 지불합니까?

다른 개발자에게 판매

어떤 사람들은 단위 테스트를 작성하는 데 인내심이 없습니다.일부는 자신의 작업을 매우 자랑스럽게 생각합니다.또는 복잡한 메서드/함수가 화면 끝에서 흘러나오는 것을 보는 것과 같은 경우도 있습니다.TDD는 모든 사람을 위한 것은 아니지만, 정말 그랬으면 좋겠습니다.코드를 상속받은 불쌍한 사람들이 물건을 관리하는 것이 훨씬 쉬워질 것입니다.

프로덕션 코드와 함께 테스트 코드 유지 관리

이상적으로는 잘못된 코드 결정을 내릴 때만 테스트가 중단됩니다.즉, 시스템이 한 방향으로 작동한다고 생각했지만 그렇지 않은 것으로 밝혀졌습니다.테스트 또는 (작은) 테스트 세트를 중단하면 이는 실제로 좋은 소식입니다.알잖아 정확히 새 코드가 시스템에 어떤 영향을 미칠지.그러나 테스트가 제대로 작성되지 않았거나, 밀접하게 결합되어 있거나, 더 나쁘게는 생성된 경우(기침 VS 테스트), 테스트를 유지하면 빠르게 합창단이 될 수 있습니다.그리고 충분한 테스트로 인해 생성되는 인식된 가치보다 더 많은 작업이 발생하기 시작한 후 일정이 압축되면 테스트가 가장 먼저 삭제됩니다(예:시간이 촉박해집니다)

모든 것을 다룰 수 있도록 테스트 작성(100% 코드 적용)

이상적으로는 방법론을 준수하면 기본적으로 코드가 100% 테스트됩니다.일반적으로 코드 적용 범위는 90% 이상이라고 생각합니다.이는 일반적으로 일부 템플릿 스타일 아키텍처가 있고 기본이 테스트되고 템플릿 사용자 정의를 테스트하지 않고 모서리를 자르려고 할 때 발생합니다.또한 이전에 직면하지 않았던 새로운 장벽에 직면했을 때 그것을 테스트하는 데 학습 곡선이 있다는 것을 발견했습니다.나는 예전 방식으로 몇 줄의 코드를 작성한다는 것을 인정하지만, 나는 그 방식을 100% 갖고 싶습니다.(내 생각엔 나는 학교에서 지나치게 성취한 사람이었던 것 같다.)

그러나 이를 통해 TDD의 이점은 응용 프로그램을 포괄하지만 한 번의 변경으로 모든 것이 깨질 정도로 취약하지 않은 좋은 테스트 세트를 달성할 수 있다면 다음과 같은 간단한 아이디어에 대한 부정적인 점보다 훨씬 크다고 말하고 싶습니다. 1일차에 했던 것처럼 프로젝트 300일차에도 새로운 기능을 계속 추가할 수 있습니다.TDD를 시도하는 모든 사람들이 버그가 많은 코드에 대한 마법의 총알이라고 생각하여 작동하지 않는다고 생각하는 사람들에게는 이런 일이 발생하지 않습니다.

개인적으로 나는 TDD를 사용하면 더 간단한 코드를 작성할 수 있고, 특정 코드 솔루션이 작동할지 여부에 대해 토론하는 데 시간을 덜 소비하며, 다음에 명시된 기준을 충족하지 않는 코드 줄을 변경하는 데 두려움이 없다는 것을 발견했습니다. 팀.

TDD는 마스터하기 힘든 분야입니다. 저는 몇 년 동안 이 분야에 종사해 왔지만 여전히 항상 새로운 테스트 기술을 배우고 있습니다.초기에는 엄청난 시간 투자가 필요하지만 장기적으로 보면 자동화된 단위 테스트가 없는 경우보다 지속 가능성이 훨씬 더 커질 것입니다.이제 내 상사만 이 문제를 알아낼 수 있다면 좋겠습니다.

첫 번째 TDD 프로젝트에는 시간과 개인의 자유라는 두 가지 큰 손실이 있습니다.

다음과 같은 이유로 시간을 잃습니다.

포괄적이고 리팩터링되었으며 유지 관리가 가능한 단위 및 승인 테스트 제품군을 생성하면 프로젝트의 첫 번째 반복에 상당한 시간이 추가됩니다.이는 장기적으로 시간을 절약할 수 있지만 마찬가지로 여유가 없는 시간이 될 수도 있습니다.
핵심 도구 세트를 선택하고 전문가가 되어야 합니다.단위 테스트 도구는 일종의 모의 프레임워크로 보완되어야 하며 둘 다 자동화된 빌드 시스템의 일부가 되어야 합니다.또한 적절한 측정항목을 선택하고 생성하려고 합니다.

다음과 같은 이유로 개인의 자유를 잃게 됩니다.

TDD는 기술 수준의 상위 및 하위에 있는 코드와 비교하여 원시적인 경향이 있는 매우 체계적인 코드 작성 방법입니다.항상 특정 방식으로 프로덕션 코드를 작성하고 지속적인 동료 검토를 받으면 최악의 개발자와 최고의 개발자를 놀라게 할 수 있으며 심지어 인원 손실로 이어질 수도 있습니다.
TDD를 포함하는 대부분의 Agile 방법에서는 달성하기로 제안하는 것(이 스토리/요일/무엇이든)과 그에 따른 절충 사항에 대해 클라이언트와 지속적으로 대화해야 합니다.다시 한번 이것은 개발자 측과 클라이언트 모두를 위한 차 한잔이 아닙니다.

도움이 되었기를 바랍니다

TDD에서는 테스트를 통과하기 위한 코드를 작성하기 전에 클래스가 어떻게 작동할지 계획해야 합니다.이것은 플러스이자 마이너스입니다.

코드가 작성되기 전에는 "진공 상태"에서 테스트를 작성하는 것이 어렵다는 것을 알았습니다.내 경험상 나는 수업을 작성하는 동안 초기 테스트를 작성할 때 잊어버린 무언가가 불가피하게 떠오를 때마다 테스트를 실수하는 경향이 있습니다.그러면 이제 수업뿐만 아니라 테스트도 리팩토링할 시간입니다.이것을 서너 번 반복하면 좌절감을 느낄 수 있습니다.

나는 먼저 수업 초안을 작성한 다음 일련의 단위 테스트를 작성하고 유지하는 것을 선호합니다.초안을 작성한 후에는 TDD가 나에게 잘 작동합니다.예를 들어 버그가 보고되면 해당 버그를 활용하는 테스트를 작성한 다음 테스트가 통과하도록 코드를 수정합니다.

TDD에서는 프로토타입 제작이 매우 어려울 수 있습니다. 솔루션을 찾기 위해 어떤 길을 택할지 확실하지 않은 경우 테스트를 미리 작성하는 것이 어려울 수 있습니다(매우 광범위한 테스트 제외).이것은 고통이 될 수 있습니다.

솔직히 저는 대다수 프로젝트의 "핵심 개발"에 실질적인 단점이 있다고 생각하지 않습니다.일반적으로 자신의 코드가 테스트가 필요하지 않을 정도로 훌륭하다고 믿는 사람들(절대 그렇지 않습니다)과 코드를 작성하는 데 애쓰지 않는 사람들이 일반적으로 필요한 것보다 훨씬 더 많이 이야기합니다.

글쎄요, 이렇게 확장하려면 테스트를 디버그해야 합니다.또한 테스트를 작성하는 데는 일정 시간 비용이 듭니다. 하지만 대부분의 사람들은 이것이 디버깅 시간 절약과 안정성 측면에서 애플리케이션의 수명 동안 성과를 거두는 선행 투자라는 데 동의합니다.

하지만 개인적으로 가장 큰 문제는 실제로 테스트를 작성하기 위한 규율을 익히는 것입니다.팀, 특히 기존 팀에서는 보낸 시간이 가치 있다는 점을 확신시키기 어려울 수 있습니다.

테스트가 철저하지 않으면 테스트를 통과했다는 이유만으로 "모든 것이 작동한다"는 잘못된 인식에 빠질 수 있습니다.이론적으로 테스트가 통과하면 코드가 작동하는 것입니다.하지만 처음부터 코드를 완벽하게 작성할 수 있다면 테스트가 필요하지 않을 것입니다.여기서의 교훈은 무언가를 완료하기 전에 스스로 온전한지 확인하는 것입니다. 테스트에만 의존하지 마십시오.

참고로, 온전성 검사에서 테스트되지 않은 항목이 발견되면 돌아가서 이에 대한 테스트를 작성하세요.

TDD의 단점은 일반적으로 'Agile' 방법론과 밀접하게 연관되어 있다는 것입니다. 아니요 테스트가 다른 값이 아닌 하나의 특정 값을 '반환해야 하는' 이유에 대한 이해는 개발자의 머리에만 있습니다.

개발자가 테스트에서 특정 값만 반환하고 다른 값은 반환하지 않는 이유를 떠나거나 잊어버리면 문제가 발생합니다.TDD는 적절하게 문서화되고 사람이 읽을 수 있는 요소로 둘러싸여 있으면 괜찮습니다(예:5년 후 세상이 변하고 앱도 변해야 할 때 참고할 수 있는 뾰족머리 관리자) 문서입니다.

문서에 대해 말할 때 이것은 코드의 설명이 아니라 관리자, 변호사 및 업데이트해야 하는 불쌍한 수액이 참조할 수 있는 사용 사례 및 배경 정보와 같이 애플리케이션 외부에 존재하는 공식 문서입니다. 2011년의 코드입니다.

나는 TDD가 나를 미치게 만드는 여러 상황에 직면했습니다.몇 가지를 언급하자면:

테스트 케이스 유지 관리성:

대기업에 있다면 테스트 케이스를 직접 작성할 필요가 없거나 적어도 회사에 입사할 때 대부분의 테스트 케이스를 다른 사람이 작성하게 될 가능성이 많습니다.응용 프로그램의 기능은 수시로 변경되며, 이를 추적할 수 있는 HP Quality Center와 같은 시스템이 없으면 금새 미쳐버릴 것입니다.

이는 또한 새로운 팀원이 테스트 케이스의 진행 상황을 파악하는 데 상당한 시간이 걸린다는 것을 의미합니다.결과적으로 이는 더 많은 돈이 필요하다는 뜻으로 해석될 수 있습니다.
테스트 자동화 복잡성:

일부 또는 모든 테스트 사례를 기계 실행 가능 테스트 스크립트로 자동화하는 경우 이러한 테스트 스크립트가 해당 수동 테스트 사례와 동기화되고 애플리케이션 변경 사항에 맞는지 확인해야 합니다.

또한 버그를 잡는 데 도움이 되는 코드를 디버깅하는 데 시간을 할애하게 됩니다.제 생각에는 이러한 버그의 대부분은 테스트 팀이 자동화 테스트 스크립트에 애플리케이션 변경 사항을 반영하지 못한 데서 비롯됩니다.비즈니스 로직, GUI 및 기타 내부 항목의 변경으로 인해 스크립트 실행이 중지되거나 불안정하게 실행될 수 있습니다.때로는 변경 사항이 매우 미묘하여 감지하기 어렵습니다.내 모든 스크립트는 테이블 1의 정보를 기반으로 계산을 수행했기 때문에 실패를 보고했지만 테이블 1은 이제 테이블 2였습니다(누군가 애플리케이션 코드에서 테이블 개체의 이름을 바꿨기 때문에).

가장 큰 문제는 적절한 단위 테스트를 작성하는 방법을 모르는 사람들입니다.그들은 서로 의존하는 테스트를 작성합니다(그리고 Ant와 함께 실행하면 훌륭하게 작동하지만 Eclipse에서 실행할 때 서로 다른 순서로 실행되기 때문에 갑자기 실패합니다).그들은 특별히 아무것도 테스트하지 않는 테스트를 작성합니다. 그들은 단지 코드를 디버깅하고, 결과를 확인하고, "test1"이라고 부르는 테스트로 변경합니다.클래스와 메서드의 범위를 넓히는 이유는 클래스와 메서드에 대한 단위 테스트를 작성하는 것이 더 쉽기 때문입니다.단위 테스트의 코드는 모든 고전적인 프로그래밍 문제(과중한 결합, 500줄 길이의 메서드, 하드 코딩된 값, 코드 중복)로 인해 끔찍하며 유지 관리가 지옥입니다.어떤 이상한 이유로 사람들은 단위 테스트를 "실제" 코드보다 열등한 것으로 취급하고 품질에는 전혀 신경 쓰지 않습니다.:-(

테스트를 작성하는 데 많은 시간을 낭비하게 됩니다.물론 버그를 더 빨리 잡아 프로젝트가 끝날 때까지 이를 저장할 수도 있습니다.

모든 코드를 테스트하기 전에 "완료"라고 말할 수 있는 능력을 잃게 됩니다.

실행하기 전에 수백 또는 수천 줄의 코드를 작성할 수 있는 능력을 잃게 됩니다.

디버깅을 통해 배울 수 있는 기회를 잃게 됩니다.

확실하지 않은 코드를 배송할 수 있는 유연성을 잃게 됩니다.

모듈을 긴밀하게 결합할 수 있는 자유를 잃게 됩니다.

낮은 수준의 설계 문서 작성을 건너뛸 수 있는 옵션을 잃게 됩니다.

모두가 변경하기를 두려워하는 코드의 안정성을 잃게 됩니다.

당신은 '해커'라는 타이틀을 잃게 됩니다.

가장 큰 단점은 정말로 TDD를 제대로 하고 싶다면 성공하기 전에 많은 실패를 겪어야 한다는 것이다.얼마나 많은 소프트웨어 회사가 일하고 있는지(KLOC당 달러)를 고려하면 결국 해고될 것입니다.코드가 더 빠르고, 깨끗하고, 유지 관리하기 쉽고, 버그가 적더라도 마찬가지입니다.

KLOC(또는 테스트되지 않은 요구 사항 구현)에 따라 급여를 지급하는 회사에서 근무하는 경우 TDD(또는 코드 검토, 쌍 프로그래밍, 지속적 통합 등)를 멀리하세요.등.등.).

두 번째는 초기 개발 시간에 대한 답변입니다.또한 테스트의 안전성이 없으면 편안하게 작업할 수 있는 능력도 잃게 됩니다.나는 또한 TDD 너트바로 설명되었으므로 친구 몇 명을 잃을 수도 있습니다.

어렵고 예상치 못한 요구 사항에 다시 초점을 맞추는 것은 프로그래머에게 끊임없는 골칫거리입니다.테스트 중심 개발은 이미 알려진 일상적인 요구 사항에 집중하도록 강요하고 개발을 이미 상상한 대로 제한합니다.

생각해 보세요. 특정 테스트 사례에 맞게 디자인하게 될 가능성이 높기 때문에 창의력을 발휘하지 못하고 "사용자가 X, Y, Z를 할 수 있다면 멋질 것"이라고 생각하기 시작할 것입니다.따라서 해당 사용자가 잠재적인 멋진 요구 사항 X, Y, Z에 대해 모두 흥분하기 시작하면 디자인이 이미 지정된 테스트 사례에 너무 엄격하게 집중되어 조정하기 어려울 수 있습니다.

물론 이것은 양날의 검이다.사용자가 원할 수 있는 모든 상상할 수 있는 X, Y, Z를 디자인하는 데 모든 시간을 소비한다면 필연적으로 아무것도 완료하지 못할 것입니다.당신이 무언가를 완성한다면, 당신이 코드/디자인에서 무엇을 하고 있는지 (당신을 포함하여) 누구도 알 수 없을 것입니다.

더 느린 것으로 인식됩니다.장기적으로 볼 때 슬픔의 측면에서는 사실이 아니지만 결국 더 많은 코드를 작성하게 되므로 "코딩이 아닌 테스트"에 시간을 소비하게 될 것입니다.그것은 결함이 있는 주장이지만, 당신은 요청했습니다!

XML 피드 및 데이터베이스와 같은 "무작위" 데이터에 대한 쓰기 테스트는 어렵고 시간이 많이 걸릴 수 있습니다(그렇게 어렵지는 않습니다).저는 최근에 날씨 데이터 피드 작업에 시간을 보냈습니다.적어도 나는 TDD에 대한 경험이 별로 없기 때문에 쓰기 테스트는 매우 혼란스럽습니다.

여러 가지 책임이 있는 대규모 수업을 잃게 됩니다.또한 여러 책임이 있는 대규모 메서드도 손실될 가능성이 높습니다.리팩토링 능력이 일부 손실될 수 있지만 리팩터링 필요성도 일부 상실됩니다.

제이슨 코헨은 다음과 같이 말했습니다.TDD에는 코드에 대한 특정 조직이 필요합니다.이는 구조적으로 잘못된 것일 수 있습니다.예를 들어 비공개 메서드는 클래스 외부에서 호출할 수 없으므로 메서드를 테스트할 수 있도록 비공개 메서드로 만들어야 합니다.

나는 이것이 추상화가 누락되었음을 의미한다고 말합니다. 전용 코드를 실제로 테스트해야 한다면 별도의 클래스에 있어야 할 것입니다.

데이브 만

다른 방식으로 애플리케이션을 작성해야 합니다.테스트 가능하게 만드는 것.처음에는 이것이 얼마나 어려운지 놀랄 것입니다.

어떤 사람들은 너무 열심히 쓰기 전에 무엇을 쓸지 생각하는 개념을 찾는다.조롱과 같은 개념은 일부 사람들에게도 어려울 수 있습니다.레거시 앱의 TDD는 테스트용으로 설계되지 않은 경우 매우 어려울 수 있습니다.TDD 친화적이지 않은 프레임워크 관련 TDD도 어려움을 겪을 수 있습니다.

TDD는 기술이므로 후배 개발자가 처음에는 어려움을 겪을 수 있습니다(주로 이런 방식으로 작업하는 방법을 배우지 않았기 때문입니다).

전반적으로 단점은 사람들이 숙련되면서 해결되고 결국 '냄새나는' 코드를 추상화하고 보다 안정적인 시스템을 갖게 됩니다.

시작하는 데 시간이 걸리고 프로젝트에서 시작하는 데도 시간이 걸리지만...나는 자동화된 테스트가 매우 빠르게 발견할 수 있었던 어리석은 버그를 발견할 때 테스트 기반 접근 방식을 수행하지 않은 것을 항상 후회합니다.또한 TDD는 코드 품질을 향상시킵니다.

단위 테스트는 작성해야 할 코드가 많아지므로 초기 개발 비용이 높아집니다.
유지 관리하는 것이 더 많은 코드입니다
추가 학습 필요

모두 좋은 답변입니다.TDD의 어두운 면을 피하기 위한 몇 가지 방법을 추가하겠습니다.

나는 무작위 자체 테스트를 수행하는 앱을 작성했습니다.특정 테스트를 작성할 때의 문제점은 많은 테스트를 작성하더라도 생각하는 사례만 다룬다는 것입니다.무작위 테스트 생성기는 사용자가 생각하지 못한 문제를 찾아냅니다.
많은 단위 테스트의 전체 개념은 복잡한 데이터 구조와 같이 유효하지 않은 상태가 될 수 있는 구성 요소가 있음을 의미합니다.복잡한 데이터 구조에서 벗어나면 테스트할 항목이 훨씬 줄어듭니다.
애플리케이션이 허용하는 한, 알림, 이벤트 및 부작용의 올바른 순서에 의존하는 디자인을 피하세요.쉽게 떨어지거나 뒤섞일 수 있으므로 많은 테스트가 필요합니다.

TDD에는 코드에 대한 특정 조직이 필요합니다.이는 비효율적이거나 읽기 어려울 수 있습니다.또는 구조적으로 잘못된 경우도 있습니다.예를 들어, 이후 private 메서드는 클래스 외부에서 호출할 수 없습니다. 메서드를 테스트 가능하게 만들려면 메서드를 비공개로 만들어야 하는데 이는 잘못된 것입니다.

코드가 변경되면 테스트도 변경해야 합니다.리팩토링을 사용하면 많은 추가 작업이 될 수 있습니다.

BDD 원칙을 TDD 프로젝트에 적용하면 여기에 나열된 몇 가지 주요 단점(혼란, 오해 등)을 완화할 수 있다는 점을 덧붙이고 싶습니다.BDD에 익숙하지 않다면 Dan North의 소개를 읽어보세요.그는 직장에서 TDD를 적용하면서 발생한 몇 가지 문제에 대한 답으로 이 개념을 생각해 냈습니다.Dan의 BDD 소개를 확인할 수 있습니다. 여기.

내가 이 제안을 하는 이유는 BDD가 이러한 부정적인 점 중 일부를 해결하고 격차 해소 역할을 하기 때문입니다.피드백을 수집할 때 이 점을 고려하는 것이 좋습니다.

테스트가 항상 최신 상태인지 확인해야 합니다. 빨간불을 무시하기 시작하는 순간은 테스트가 의미가 없게 되는 순간입니다.

또한 테스트가 포괄적인지 확인해야 합니다. 그렇지 않으면 큰 버그가 나타나는 순간 더 많은 코드를 작성하는 데 시간을 할애할 수 있다고 확신한 답답한 관리 유형이 불평할 것입니다.

우리 팀에 애자일 개발을 가르친 사람은 계획을 믿지 않았습니다. 당신은 아주 작은 요구 사항에 대해서만 많은 것을 썼습니다.

그의 모토는 리팩터링, 리팩터링, 리팩터링이었습니다.나는 리팩토링이 '미리 계획하지 않음'을 의미한다는 것을 이해하게 되었습니다.

개발 시간 증가:모든 방법에는 테스트가 필요하며 종속성이 있는 대규모 애플리케이션이 있는 경우 테스트를 위해 데이터를 준비하고 정리해야 합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow