TDD 부정적인 경험 [폐쇄]

TDD 경험의 부정적인면은 무엇입니까? 아기 발걸음 (테스트 녹색을 만드는 가장 간단한 수정)이 성 가시고 쓸모가 없습니까? 가치가없는 테스트 (테스트가 초기에 의미가 있지만 최종 구현에서 다른 테스트와 동일한 논리를 검사 할 때)가 중요하다는 것을 알고 있습니까? 기타

위의 질문은 TDD 경험 중에 불편한 것에 관한 것입니다. 그래서 다른 개발자들이 비슷한 감정을 가지고 있는지, 어떻게 생각하는지에 관심이 있습니다.

TDD의 부정적인 측면을 설명하는 기사에 대한 링크에 감사드립니다 (Google은 긍정적이고 종종 광신적 인 기사로 가득합니다).

"Agile"배너 아래에 나오는 모든 것과 마찬가지로 TDD는 이론적으로는 좋은 것으로 보이지만 실제로는 그것이 얼마나 좋은지 명확하지 않습니다 (또한 대부분의 "Agile"과 마찬가지로, 그렇지 않으면 그 것처럼, 당신은 잘못하고 있습니다).

켄트 벡 (Kent Beck)과 같은 사람들은 비 컴파일 테스트를 한 줄의 코드보다 먼저 작성해야하고 모든 한 줄의 코드는 실패한 테스트를 통과하도록 작성해야합니다. 전면 디자인이 최소화되어 모든 것이 구동됩니다테스트에 의해. 작동하지 않습니다. 나는 그 방법론을 사용하여 개발 된 큰 엔터프라이즈 응용 프로그램을 보았고 그것이 내 경력에서 볼 수있는 더 나쁜 코드이기를 희망합니다 (멀리 지 않을 것입니다. 내가 본 것에서 함수 호출이 발생했는지 주로 검증하고 변수가 null이고 조롱 프레임 워크가 철저한 운동 (whoop-de-whoop)을 얻었을 때 예외가 발생한다는 것을 주로 검증하는 많은 수의 잘못 생각한 테스트가 발생합니다. 프로덕션 코드는 이러한 테스트와 밀접한 관련이 있으며 지속적이고 쉬운 리팩토링의 꿈은 나타나지 않습니다. 실제로 사람들은 모든 테스트로 인해 잘못된 코드를 고칠 가능성이 적습니다.

반대로 나는 사람들이 TDD가 계획 단계의 일환으로 건축 설계와 함께 높은 수준에서 테스트를 설계하는 것을 의미한다고 주장하는 것을 들었습니다. 이러한 테스트는 추가 정보를 사용할 수있게되면 개발 중에 변경 될 수 있지만 코드를 신중하게 고려하여 코드가 실제로 수행해야하는 작업에 대한 좋은 가이드를 제공합니다. 나에게 그것은 완벽하게 이해됩니다.

이 ( Clojure 저자) Rich Hickey 인터뷰 에는 다음이 포함됩니다. 나는 100 % 동정심을 느낀다 :

인생은 짧고 하루에 한정된 시간 만 있습니다. 따라서 우리는 시간을 어떻게 보내야하는지 선택해야합니다. 테스트를 작성하는 데 소비한다면, 다른 일을하지 않는 시간입니다. 우리 각자는 수량과 품질면에서 결과를 극대화하기 위해 시간을 가장 잘 보내는 방법을 평가해야합니다. 사람들이 테스트 작성 시간의 50 %를 소비하면 결과가 극대화된다고 생각하면 알 수 있습니다. 나는 그것이 사실이 아니라고 확신한다. 오히려 내 문제에 대해 생각하면서 그 시간을 보내고 싶다. 나는 이것이 내가 다른 시간을 사용하는 것보다 적은 결함으로 더 나은 솔루션을 생산할 것이라고 확신합니다. 완벽한 테스트 스위트를 갖춘 나쁜 디자인은 여전히 ​​나쁜 디자인입니다.

Workbook 인터뷰 에서 코더의 도널드 크 누스 (Donald Knuth)의 또 다른 비슷한 진술 은 여기 에서 복사하여 붙여 넣 습니다 .

Seibel : 컴퓨터 프로그래밍 기술에 대한 실습에서 실용적인 작업에 대해 말하면서 조판 시스템 TeX를 작성하기 위해 10 년의 휴식 시간을 가졌습니다. 컴퓨터에서 완전히 떨어져있는 첫 번째 버전의 TeX를 작성하신 것으로 알고 있습니다.

Knuth : 1977 년과 78 년에 TeX를 처음 썼을 때, 글을 읽고 쓸 줄 모르는 프로그래밍은 없었지만 구조화 된 프로그래밍을했습니다. 나는 큰 노트에 손으로 연필로 썼습니다. 6 개월 후, 전체 프로젝트를 마친 후 컴퓨터에 들어가기 시작했습니다. 그리고 77 년 10 월에 프로그램 작성을 시작하면서 78 년 3 월에 디버깅을했습니다. 이를위한 코드는 스탠포드 아카이브에 있으며, 연필로되어 있습니다. 물론 서브 루틴을 다시 가져 와서 변경해야 할 내용을 알았습니다. 이것은 1 세대 시스템 이었기 때문에 많은 다른 아키텍처가 가능했고, 한동안 살면서 그곳에 무엇이 있는지 알 때까지 버려야했습니다. 그리고 그것은 닭과 계란 문제였습니다. 서체를 가질 때까지 조판 할 수 없었지만 조판 할 때까지 서체를 가질 수 없었습니다. 그러나 구조적 프로그래밍은 불변의 아이디어와 내가 이해할 수있는 블랙 박스를 만드는 방법을 알았습니다. 그래서 마침내 코드를 디버깅 할 때 코드가 작동 할 것이라고 확신했습니다. 테스트하기 전에 6 개월을 기다리면 많은 시간을 절약 할 수 있다고 생각했습니다. 코드가 거의 옳았다는 확신이 충분했습니다.

Seibel : 그리고 시간을 절약 할 수 있다면 비계 코드와 스텁을 작성하여 불완전한 코드를 테스트하는 데 시간을 소비하지 않습니까?

Knuth : 그렇습니다.

TDD에 대한 나의 부정적인 경험은 나의 첫 경험이었습니다. TDD는 나에게 큰 소리를 냈고, 수년간 QA를 해왔지만 여전히 내 마음에 공포가 생겼습니다. 빌드하기 전에 모든 버그를 없애고 싶었습니다. 불행히도 TDD를 사용한다고해서 좋은 시험을한다고 보장 할 수는 없습니다. 사실, 나의 초기 성향은 간단한 코드를 생성하는 간단한 테스트를 작성하는 것이 었습니다. 추상화가 거의없는 간단한 코드. 클래스 내부와 얽힌 매우 간단한 테스트. 그리고 몇 번의 itty bitty 테스트가 완료되면 매우 중요한 도메인 개념 X를 사용하도록 코드를 리팩토링하기 위해 수백 개의 테스트를 변경해야 할 때 더 빨리 움직이고 있다고 느끼지 않을 것입니다.

TDD는 테스트 기술이 아닙니다. 디자인 기술입니다. 실습을 통해 우수하고 단순하며 실행 가능한 코드로 인도 할 수 있으며, 설계 방향을 지속적으로 인식 할 수 있습니다. 코드 적용을 위해 테스트를 작성하는 경우 취성 테스트를 작성하게됩니다. 추상화를 디자인하는 데 도움이되는 테스트를 작성하는 경우 하향식 코드를 작성하는보다 엄격한 방법입니다. 호출자의 관점에서 먼저 코드를 볼 수 있으므로 클래스의 내부를 외부 가장자리에 미러링하는 대신 그의 삶을 더 쉽게 만들 수 있습니다.

나는 TDD가 유용하다고 생각하지만 그것에 대해 독단적이지는 않습니다. 이러한 "무가치 테스트"로 인해 유지 보수가 어려워지는 경우-삭제하십시오! 테스트를 나머지 코드와 같은 방식으로 처리합니다. 리팩토링하여 더 간단하게 만들 수 있다면 그렇게하십시오!

개인적으로 보지는 못했지만 일부 지역에서는 코드 범위와 테스트 횟수를 추적한다고 들었습니다. 따라서 메트릭 수집이 TDD의 부작용 인 경우 부정적인 것으로 볼 수도 있습니다. 나는 1000 줄의 코드를 열정적으로 삭제하고 20 번의 테스트를 폐기하고 코드 적용 범위를 % 떨어 뜨립니다.

나는 여기서 사지로 나가서 말 그대로 의식적인 시간 낭비 라는 잔인한 정직성을 선언 할 것입니다 . (대부분의 상황에서)

나는 TDD에 관해 논의한 Unit Testing에 관한 책을 샀고, UT의 이점에 동의하는 동안, 약 100 시간의 TDD를 시도한 후에, 나는 수많은 이유로 그것을 포기했습니다. 나는 여기 에 교차 게시 하고 있지만 TDD :

1. 실제 문서보다 더 나은 문서는 아닙니다.
2. 버그 나 회귀를 포착하지 않습니다 .
3. 함수형 프로그래밍과 컴포저 빌 러티 개념을 적용하면 디자인이 실제로 나아지는 것보다 실제로 더 나은 것은 아닙니다 .
4. 코드 검토를 수행하거나 문서 및 사양을 연마하는 데 더 나은 시간입니다.
5. 수백 개의 녹색 아이콘 목록을 볼 때 관리자에게 잘못된 보안 감각을 부여합니다.
6. 제한된 입 / 출력 매핑으로 알고리즘 구현의 생산성을 향상시킵니다.
7. 당신이 TDD의 결과로 무엇을하고 있는지 알 수 있다는 점에서 서툴지 만 , 왜 그렇게 잘 작동하는지, 왜 디자인이 그 방식 대로 나오는지 이해 하지 못하고 있습니다.

또 다른 문제는 TDD가 성공적으로 수행해야하는 논쟁의 완전성입니다. 일부는 프로젝트 시작부터 팀의 모든 사람이 TDD를 지속적으로 수행하지 않으면 어려움을 겪을 것이라고 주장합니다. 다른 사람들은 아무도이 책으로 TDD를하지 않는다고 주장합니다. 이 두 가지가 모두 사실이라면, TDD 실무자들은 그것을 깨닫 든 모르 든 고통을 겪습니다.

물론, TDD와 같은 방식으로 일을함으로써 TDD와 쉽게 작동 할 수있는 디자인이 나오게 될 것입니다. 구성 성. 거기에는 많은 자료가 있으며 엄밀한 수학 이론도 있습니다 (대부분 함수 프로그래밍뿐만 아니라 다른 분야에서도). 모든 TDD 시간을 배우는 데 시간을 보내지 않겠습니까?

문화적으로 TDD는 의식적 관행의 증상을 보여줍니다. 죄책감이 듭니다. 그것은 이해보다는 절차를 장려한다. 그것은 많은 교리와 슬로건을 가지고 있습니다 ( "당신이 그것을 만들 때까지 가짜"는 당신이 그것을 객관적으로 보면 정말 놀랍습니다). "의식"이라는 단어에 대한 Wikipedia의 정의는 실제로 매우 apposite입니다.

심리학에서, 의식 이라는 용어 는 때때로 사람이 불안을 중화하거나 예방하기 위해 체계적으로 사용하는 반복적 인 행동에 대해 기술적 의미로 사용됩니다. 강박 장애의 증상입니다.

또한 TDD와 관련하여 또 다른 관심사는 다음과 같습니다.

TDD로 인해 개발 팀의 초점 이 실수로 Quality Code에서 Testcases 및 Code Coverage 로 전환되었습니다 ! 나는 개인적으로 TDD를 좋아하지 않아서 창의력이 떨어지고 소프트웨어 개발이 둔한 기계 프로세스가되었습니다 ! 단위 테스트 케이스는 신중하게 사용하면 유용하지만 소프트웨어 개발 목표를 다룰 때 부담이됩니다.

나는 관리자이며 기술적으로 둔한 사람을 알고 TDD에 집착했습니다. 그는 유지 관리가 거의 불가능한 저조한 ​​소프트웨어의 모든 문제에 대해 마법의 해결책을 가져올 것이라고 믿었던 것은 그에게 놀라운 일이었습니다. 그의 프로젝트에서 일어난 일은 말할 것도없고 그의 테스트 케이스는 모두 녹색 인 반면에 그의 손에는 비참하게 실패했습니다. 나는 TDD가 "99/100의 내 사건은 초록색"과 같은 통계 정보를 얻는 데 도움이 되었기 때문에 품질을 평가하거나 디자인의 개선을 제안 할 수 없었기 때문에 그의 집착 이유가되었다.

저의 주요 부정적인 경험은 TDD를 사용하여 테스트가 없거나 매우 기본적인 통합 테스트가없는 다른 프로그래머의 코드를 편집하려고합니다. 기능을 추가하거나 해당 코드의 문제를 해결하려고 할 때; 먼저 테스트를 작성하는 것을 선호합니다 (TDD 방식). 불행히도 코드는 밀접하게 결합되어 있으며 리팩토링이 없으면 테스트 할 수 없습니다.

리팩토링 어쨌든 좋은 운동이지만되어 필요한 시험 가능한 상태로 코드를 얻을 수 있습니다. 그리고이 단계 후에, 나는 나의 변화가 무엇을했는지 확인하기위한 점검과 균형이 없습니다. 응용 프로그램을 실행하고 모든 사용 사례를 검사하지 않습니다.

반면에 TDD 프로젝트에 기능 / 수정 버그를 추가하는 것은 매우 간단합니다. 본질적으로 TDD로 작성된 코드는 일반적으로 작업하기 위해 작은 조각으로 분리됩니다.

어쨌든 TDD는 지침입니다. 효과를 극대화 할 수있는 지점까지 따르십시오. 적절한 테스트 범위와 분리 된 코드, 잘 작성된 코드

시스템 설계와 관련하여 테스트에 너무 의존하는 경험을했습니다. 나는 기본적으로 너무 큰 구현 세부 사항에서 너무 낮아서 더 큰 그림을보기 위해 발걸음을 내딛었습니다. 이것은 종종 불필요하게 복잡한 디자인을 초래합니다. 나는 코드를 리팩토링해야하지만 때로는 단계를 더 자주 되돌려 많은 시간을 절약 할 수 있다는 인상을받습니다.

즉, 아키텍처 결정이 매우 제한적인 레일과 같은 프레임 워크가 있다면 이러한 문제는 기본적으로 존재하지 않습니다.

또 다른 문제는 테스트를 맹목적으로 신뢰할 때입니다. 진실은 다른 코드와 마찬가지로 테스트에도 버그가있을 수 있습니다. 따라서 구현에 대한 테스트만큼 중요합니다.

TDD의 큰 팬으로서 나는 때때로 이러한 단점을 본다

• 거의 100 % 코드 적용을 위해 너무 많은 테스트를 작성하려는 유혹 . 내 생각에는 테스트를 작성할 필요가 없습니다.
  • 간단한 속성 게터 / 세터
  • 예외가 발생할 때마다
  • 다른 레이어를 통해 동일한 기능을 검사합니다. (예 : 모든 매개 변수에 대한 입력 유효성 검사를 확인하기위한 단위 테스트가있는 경우 통합 테스트를 통해 이러한 모든 테스트를 반복 할 필요는 없습니다)

• 유사한 테스트에 대한 테스트 코드의 유지 관리 비용은 약간만 다릅니다 (코드 복제 (일명 복사 붙여 넣기 상속)). 이미 가지고 있다면 비슷한 것을 쉽게 만들 수 있습니다. 그러나 테스트 코드를 리팩터링하지 않으면 헬퍼 메소드로 코드 중복을 제거하여 비즈니스 코드의 구현 세부 사항이 변경되면 테스트를 수정하는 데 약간의 시간이 필요할 수 있습니다.

• 당신이 아래의 경우 시간 압력 당신을 유혹 할 수있다 깨진 테스트를 제거 (또는 그들을 주석) 대신에 고정의 를. 이 방법으로 테스트에 대한 투자를 잃게됩니다

TDD가 가치있는 게임 개발자로서 하나 이상의 시나리오를 아직 보지 못했습니다. 그리고 그 예는 순전히 수학적으로 작성된 코드 조각으로, 수많은 엣지 케이스를 동시에 테스트하기위한 견고한 접근 방식이 필요했습니다.

어쩌면 언젠가는 내 마음이 바뀔지 모르지만 XP 관행 중에서도 무자비하게 리팩토링 한다는 개념 과 자체 형태로 발전하는 코드 가 훨씬 더 중요하며 생산성이 가장 뛰어납니다. James Newkirk가 작성한 논문 의 인용문 :

단순성- "작동 할 수있는 가장 간단한 것은 무엇입니까?"
그 메시지는 매우 분명하다. 오늘날의 요구 사항을 고려하여 소프트웨어를 설계하고 작성하십시오. 미래를 예측하려고하지 말고 미래를 전개 시키십시오. 예측을 예측할 수없는 방법으로 수행 할 수 있습니다.

그가 언급 한 용기 와 피드백 루프 강화 개념은 생산성의 핵심이기도합니다.

제한적인 나의 TDD 경험은 단순히 어디서부터 시작해야하는지 아는 것입니다! 예를 들어, 나는 TDD를 시도하고 사소한 것들을 테스트하기 시작하는 곳을 알지 못합니다 ( Foo객체를 새로 만들거나 Quux에 전달할 수 있습니까? 등) Baz. ) 또는 기존 프로젝트에서 구현하려고하면 TDD에서 사용할 수 있도록 다양한 클래스를 다시 작성해야한다는 것을 알았습니다. 결과적으로 나는 그 개념을 완전히 포기했다.

단위 테스트 (TDD 또는 기타)가 무엇인지, 왜 이것이 좋은지를 아는 회사 전체에서 유일한 사람이라는 것은 종종 도움이되지 않습니다.

TDD 열광 자.

나를 위해, 그들은 내 문을 두드리는 긴 종교적 루니 중 하나 일뿐입니다. 제 일을하는 나의 길은 돌이킬 수 없을 정도로 깨졌으며 구원의 유일한 길은 예수, 켄트 백 또는 단위 테스트입니다.

IMO의 가장 큰 거짓말은 TDD가 더 나은 알고리즘 디자인 으로 구원 을 이끌어 줄 것 입니다. TDD로 작성된 유명한 Soduku 솔버를 참조하십시오 : here , here , here , here 및 here

그리고 Peter Norvig 스도쿠 솔버는 TDD를 사용하지 않고 구식 엔지니어링을 사용하여 비교했습니다 : http://norvig.com/sudoku.html

이 "광신적 인"기사에서 TDD를 사용하면 소프트웨어에 오류가 없다는 잘못된 안전감을 느끼게됩니다.

TDD에는 몇 가지 이점이 있습니다.

• 당신은에 집중 하는 방법 대신 문제 해결에 집중 한 다음 응용 프로그램에서 전화에 접착제 (먼저 테스트를 작성할 때) 코드와 무엇을 먼저 기대를 호출합니다. 모듈화는 조롱하고 감싸기가 더 쉽습니다.
• 테스트는 리팩토링 전후에 프로그램이 동일하게 작동하는지 확인합니다. 이것은 프로그램에 오류가 없음을 의미하지는 않지만 동일한 방식으로 계속 작동합니다.

TDD는 장기 투자에 관한 것입니다. 이러한 노력은 애플리케이션의 유지 관리 모드에 도달 할 때 효과가 있으며, 해당 시점에 도달 할 계획이없는 경우 투자를 복구 할 수 없습니다.

나는 비행기에 대한 점검표와 비슷한 아기 단계가있는 TDD 적록주기를 고려합니다. 비행기가 이륙하기 전에 비행기의 모든 것을 점검하는 것은 성 가시고 지루합니다. 특히 그것이 간단하지 않은 경우 (TDD 베이비 스텝) 안전이 증가하는 것으로 밝혀졌습니다. 모든 것이 작동하는지 확인하는 것 외에도 평면을 재설정합니다 . 즉, 비행기가 이륙하기 전에 재부팅됩니다.

TDD에 대한 나의 부정적인 경험은 내가 새롭고 과장된 것들로 느끼는 것입니다. 실제로 TDD는 코드의 유효성을 보장하기 때문에 TDD를 즐기고 더 중요합니다. 새 코드 또는 모든 종류의 리팩토링을 추가 한 후 실패한 테스트를 인식 할 수 있습니다.

TDD에 대해 짜증나는 것은 그것에 관한 많은 규칙이나 지침이 있다는 사실입니다. 아직까지는 매우 새롭기 때문에 대부분의 사람들은 TDD 초보자입니다. 따라서 우리 중 일부에게는 효과가 좋은 것이 다른 사람들에게는 효과가 없을 수도 있습니다. 내가 말하고 싶은 것은 TDD를 수행하는 실제 "잘못되거나 올바른"방법이 없다는 것입니다. 저와 제 팀이 있다면 저에게 효과적입니다.

따라서 테스트를 작성하는 한-프로덕션 코드 전후에 실제로 IMHO가 중요하지 않습니다-테스트 기반이 실제로 아직 입증되지 않았기 때문에 지금 명시된 모든 지침을 따라야하는지 확실하지 않습니다. 일상 업무에 이상적인 솔루션입니다. 테스트를 작성하는 더 좋은 방법을 찾으면 블로그에 게시하거나 여기에서 토론하거나 기사를 작성해야합니다. 따라서 10 년 정도면 어떤 상황에서 어떤 TDD 규칙이 양호하다고 가정 할 수 있는지를 알 수있을만큼 충분한 경험을 공유했을 수 있습니다.

한 번 이상 서투른 다음 날 버린 코드를 작성했습니다. TDD로 다시 시작했는데 솔루션이 더 좋았습니다. 그래서 나는 부정적인 TDD 경험의 라인에 너무 많지 않았습니다. 그러나 나는 TDD 공간 밖에서 문제에 대해 생각하고 더 나은 솔루션을 생각해내는 데 시간을 보냈습니다 .

긴급 시스템에서 TDD가 제대로 작동하지 않는 것을 발견했습니다. 저는 비디오 게임 개발자이며 최근에 TDD를 사용하여 여러 간단한 동작을 사용하여 실체에 대한 사실적인 움직임을 만드는 시스템을 만들었습니다.

예를 들어, 다른 유형의 위험 지역에서 멀어지게하는 행동과 다른 유형의 흥미로운 영역으로 이동하는 데 책임이있는 행동이 있습니다. 각 행동의 결과를 합치면 최종 움직임이 발생합니다.

시스템의 내장은 쉽게 구현되었으며 TDD는 여기서 각 서브 시스템이 담당해야하는 것을 지정하는 데 유용했습니다.

그러나 행동이 어떻게 상호 작용하는지, 더 중요하게는 시간이 지남에 따라 어떻게 상호 작용 하는지를 지정할 때 문제가 발생했습니다. 종종 정답이 없었으며 초기 테스트가 통과되었지만 QA는 시스템이 작동하지 않는 최첨단 사례를 계속 찾을 수있었습니다. 올바른 해결책을 찾기 위해 몇 가지 다른 행동을 반복해야했고 게임에서 작동하기 전에 새로운 동작을 반영하기 위해 매번 테스트를 업데이트하면 테스트 시간과 시간을 다시 포기했을 수 있습니다. 그래서 그 테스트를 삭제했습니다.

나는 아마도 QA 발견 가장자리 케이스를 캡처 한 강력한 테스트를 했어야하지만, 많은 물리학 및 게임 플레이 시스템의 꼭대기에 앉아 그 같은 시스템을 가지고, 때 와 당신이 시간이 지남에 따라 행동 상대하고, 그것은 조금이된다 무슨 일이 일어나고 있는지 정확히 명시하는 악몽.

나는 거의 확실히 내 접근 방식에서 실수를 저질렀 고, 시스템의 장에 대해 말했듯이 TDD는 훌륭하게 작동했으며 심지어 최적화 된 리 팩터를 지원했습니다.