TDD 대 단위 테스트 [닫힘]

우리 회사는 코드 단위 테스트를 처음 접했습니다. 나는 TDD와 단위 테스트에 대해 얼마 동안 읽었으며 그 가치를 확신합니다. 나는 TDD가 우리가 프로그램하는 방법에 대한 우리의 사고 방식을 배우고 바꾸는 노력의 가치가 있다고 우리 팀을 설득하려고 시도했지만 그것은 어려움입니다. 내 질문으로 이동합니다.

TDD 커뮤니티에는 테스트를 작성하고 코드를 작성하는 데 매우 종교적인 사람들이 많이 있지만 TDD로 어려움을 겪고있는 팀의 경우 타협이 여전히 추가 이점을 제공합니까?

코드가 작성되면 (아마도 코드 체크인을위한 요구 사항으로) 팀이 단위 테스트를 작성하도록하는 데 성공할 수 있으며, 이러한 단위 테스트를 작성하는 데 여전히 가치가 있다고 가정합니다.

고군분투하는 팀을 TDD에 도입하는 가장 좋은 방법은 무엇입니까? 그리고 실패해도 코드가 작성된 후에도 단위 테스트를 작성할 가치가 있습니까?

편집하다

여기서 빼 놓은 것은 코딩 프로세스의 어딘가에서 단위 테스트를 시작하는 것이 중요하다는 것입니다. 컨셉을 선택하는 팀원의 경우 TDD로 더 이동하고 먼저 테스트하십시오. 모두의 의견에 감사드립니다.

후속 조치

우리는 최근에 새로운 소규모 프로젝트를 시작했고 팀의 일부는 TDD를 사용했고 나머지는 코드 이후에 단위 테스트를 작성했습니다. 프로젝트의 코딩 부분을 마무리 한 후, 코드 이후에 단위 테스트를 작성하는 사람들은 TDD 코더가 이미 완료되고 더 견고한 코드를 사용하는 것을보고 놀랐습니다. 회의론자들을 이길 수있는 좋은 방법이었습니다. 앞으로도 성장통이 많이 남아 있지만 의지의 싸움은 끝난 것 같습니다. 조언을 해주신 모든 분들께 감사드립니다!

팀이 TDD를 구현하는 데 어려움을 겪고 있지만 이전에 단위 테스트를 만들지 않았다면 코드가 작성된 후 단위 테스트를 만들어 시작하십시오. 코드 다음에 작성된 단위 테스트조차도 단위 테스트가없는 것보다 낫습니다!

유닛 테스팅 (및 그와 함께 제공되는 모든 것)에 능숙 해지면 먼저 테스트를 만들고 두 번째로 코드를 작성하도록 할 수 있습니다.

코드가 작성된 후에도 단위 테스트를 작성하는 것은 절대적으로 가치가 있습니다. 코드가 테스트 할 수 있도록 설계되지 않았기 때문에 때때로 더 어렵고 지나치게 복잡 할 수도 있습니다.

팀을 TDD에 도입하는 좋은 실용적인 방법은 전환 기간 또는 장기적으로 "개발 중 테스트"의 대체 방법을 제공하는 것입니다. 그들은 자연스럽게 보이는 TDD 코드 섹션을 권장해야합니다. 그러나 테스트 우선 접근하기 어려운 코드 섹션이나 민첩하지 않은 A & D 프로세스에 의해 미리 결정된 객체를 사용할 때 개발자는 코드의 작은 섹션을 작성한 다음이를 포함하는 테스트를 작성할 수 있습니다. 이 과정을 반복합니다. 코드를 작성한 직후에 일부 코드에 대한 단위 테스트를 작성하는 것이 단위 테스트를 전혀 작성하지 않는 것보다 낫습니다.

"코드 우선, 이후 테스트"및 100 % 완성 된 라이브러리로 50 % 테스트 커버리지를 갖는 것이 저의 겸손한 의견입니다. 100 % 테스트 커버리지와 TDD로 50 % 완성 된 라이브러리보다 낫습니다. 잠시 후 동료 개발자가 작성한 모든 public코드에 대한 테스트를 작성하는 것이 재미 있고 교육적이라는 것을 알게 될 것이므로 TDD는 개발 루틴에 몰래 들어갈 것입니다.

저는 달력에서 이것을 읽었습니다. "최대한 실행 된 모든 규칙은 우스꽝 스럽거나 심지어 위험 해집니다." 그래서 내 제안은 그것에 대해 종교적이지 않다는 것입니다. 팀의 모든 구성원은 테스트와 관련하여 "옳다"고 느끼는 것 사이의 균형을 찾아야합니다. 이렇게하면 팀의 모든 구성원이 가장 생산적이 될 것입니다 ( "왜이 sti **** 테스트를 작성해야합니까?"라고 생각하는 대신).

따라서 일부 테스트는없는 것보다 낫고, 코드 이후의 테스트는 몇 번의 테스트보다 낫고 코드 이전의 테스트는 이후보다 낫습니다. 그러나 각 단계에는 고유 한 장점이 있으며 작은 단계라도 눈살을 찌푸 리지 마십시오.

TDD는 디자인에 관한 것입니다! 따라서이를 사용하면 테스트 가능한 코드 디자인을 확보하여 테스트를 더 쉽게 작성할 수 있습니다. 코드를 작성한 후 테스트를 작성하면 여전히 가치가 있지만 IMHO는 테스트 가능한 디자인이 없기 때문에 시간을 낭비하게 될 것입니다.

팀이 TDD를 채택하도록 설득 할 수있는 한 가지 제안은 Mary Lynn Manns와 Linda Rising이 작성한 Fearless Change : Patterns for Introducing New Ideas에 설명 된 몇 가지 기술을 사용하는 것입니다 .

IMO보다 테스트가 처음이라면 이미 작성된 코드 테스트를 시작하고 먼저 테스트 작성으로 천천히 진행하십시오. TDD를 배우고 단위 테스트를 처음 접하는 사람으로서 저는 완전한 180도를 수행하고 코드 전에 테스트를 작성하려는 마음가짐을 변경하는 것이 다소 어렵다는 것을 알게되었습니다. 그래서 제가 취하는 접근 방식은 일종의 50-50 믹스입니다. ; 코드가 어떻게 생겼는지 정확히 알면 코드를 작성한 다음 테스트를 작성하여 확인합니다. 확실하지 않은 상황에서는 테스트로 시작하여 거꾸로 작업합니다.

또한 테스트를 만족시키기 위해 코드를 작성하는 대신 코드를 확인하기 위해 테스트를 작성하는 데 아무런 문제가 없음을 기억하십시오. 팀이 TDD 경로로 가고 싶지 않다면 강요하지 마십시오.

코드가 작성되면 (아마도 코드 체크인을위한 요구 사항으로) 팀이 단위 테스트를 작성하도록하는 데 성공할 수 있으며, 이러한 단위 테스트를 작성하는 데 여전히 가치가 있다고 가정합니다.

단위 테스트 코드에 가치가 있다는 사실에는 의심의 여지가 없으며 (테스트 작성시기에 관계없이) "완료 정의"에 "코드가 단위 테스트 됨"을 포함합니다. 사람들은 테스트하는 한 TDD를 사용하거나 사용하지 않을 수 있습니다.

버전 제어와 관련하여 저는 단위 테스트 정책 (즉, 코드 컴파일 및 빌드, 모든 단위 테스트 통과) 과 함께 " 개발 분기 " 를 사용하는 것을 좋아합니다 . 기능이 완료되면 개발 분기에서 트렁크로 게시됩니다. 즉, 트렁크 브랜치는 " Done 브랜치 "(트렁크에 정크 없음!)이며 배송 가능한 정책 (언제든지 릴리스 가능)이 있으며 "단위 테스트"보다 더 많은 것을 포함합니다.

이것은 당신의 팀이 그것을 믿기 시작하기 전에 자신의 성공을 가져야 할 것입니다. 나는 관심있는 사람을 위해 나의 nUnit 에피파니에 대해 불평 할 것입니다.

약 5 년 전에 프로젝트 작업을 할 때 nUnit을 발견했습니다. 우리는 V1.0을 거의 완성했고이 새로운 도구를 시험해보기 위해 몇 가지 테스트를 만들었습니다. 우리는 새로운 팀이었고, 촉박 한 기한, 높은 기대 (친숙하게 들리나요?) 등등으로 인해 많은 버그가있었습니다. 어쨌든 우리는 1.0에 들어가 1.1에서 시작했습니다. 우리는 팀을 약간 재구성했고 2 명의 개발자를 배정 받았습니다. 나는 그들에게 1 시간 동안 데모를했고 우리가 작성한 모든 것에는 테스트 케이스가 있어야한다고 말했습니다. 우리는 더 많은 코드, 단위 테스트를 작성하고 있었기 때문에 1.1 개발주기 동안 나머지 팀의 "뒤에서"계속 실행했습니다. 결국 더 많은 작업을했지만 여기에 그 대가가 있습니다. 마침내 테스트를 시작했을 때 코드에 정확히 0 개의 버그가있었습니다. 우리는 다른 모든 사람들이 버그를 디버그하고 복구하도록 도왔습니다. 사후 분석에서 버그 수가 나타 났을 때

나는 당신이 성공으로가는 길을 시험 할 수 있다고 생각할만큼 멍청하지는 않지만 단위 테스트에 관해서는 진정한 신자입니다. 이 프로젝트는 nUnit을 채택했으며 곧 1 번의 성공으로 모든 .Net 프로젝트를 위해 회사로 퍼졌습니다. V1.1 릴리스의 총 기간은 개발 주 9 주 였으므로 하룻밤 사이에 성공하지 못했습니다. 그러나 장기적으로는 우리 프로젝트와 우리가 솔루션을 구축 한 회사에서 성공을 거두었습니다.

테스트 (First, While 또는 After)가 베이컨을 절약하고 생산성과 자신감을 향상시킬 것이라는 데는 의심의 여지가 없습니다. 나는 그것을 채택하는 것이 좋습니다!

저도 비슷한 상황에 처했습니다. 저는 "멍청한"개발자 였기 때문에 팀 프로젝트 작업을 할 때 기여로 인해 빌드가 망가 졌다는 사실에 종종 좌절했습니다. 나는 내가 탓해야하는지, 어떤 경우에는 누구를 탓해야하는지 몰랐다. 그러나 나는 동료 개발자들에게 똑같은 일을하고 있다는 것이 더 걱정되었습니다. 이 실현은 TDD 전략을 채택하도록 동기를 부여했습니다. 우리 팀은 모든 테스트가 통과 될 때까지 집에 갈 수없는 어리석은 게임과 규칙을 시작했습니다. 또는 테스트없이 무언가를 제출하면 모두 "맥주 / 점심 식사 / 기타"를 사야하고 TDD가 더 재미있게 만들었습니다.

단위 테스트의 가장 유용한 측면 중 하나는 이미 작동중인 코드의 지속적인 정확성을 보장하는 것입니다. 마음대로 리팩토링 할 수있을 때 IDE가 컴파일 시간 오류를 상기 시키도록 한 다음 버튼을 클릭하여 테스트에서 잠재적 인 런타임 오류를 발견 할 수 있도록합니다. TDD에 감사하기 시작했습니다. 따라서 기존 코드 테스트부터 시작하는 것이 확실히 유용합니다.

또한 솔직히 말해서 TDD로 시작하는 것보다 작성된 코드를 테스트하여 테스트 가능한 코드를 작성하는 방법에 대해 더 많이 배웠습니다. 최종 목표를 달성하고 테스트를 허용하는 계약을 생각하려는 경우 처음에는 너무 추상적 일 수 있습니다. 그러나 코드를보고 "여기에있는이 싱글 톤은 종속성 주입을 완전히 망쳐 놓고 테스트를 불가능하게 만듭니다"라고 말할 수있을 때 어떤 패턴이 테스트 생활을 더 쉽게 만들어 주는지에 대한 인식을 발전시키기 시작합니다.

글쎄, 먼저 테스트를 작성하지 않으면 "테스트 주도"가 아니라 테스트 일뿐입니다. 그것은 그 자체로 이점을 가지고 있으며 테스트를 추가하는 코드 기반이 있다면 TDD가 아니라 단순히 테스트하더라도 확실히 유용합니다.

테스트를 먼저 작성하는 것은 코드를 작성하기 전에 수행해야하는 작업에 초점을 맞추는 것입니다. 예, 당신은 또한 그것을하는 테스트를 받고 좋습니다. 그러나 어떤 사람들은 그것이 가장 중요한 요점조차 아니라고 주장 할 수 있습니다.

내가 할 일은 TDD를 사용하여 이와 같은 장난감 프로젝트 (Coding Dojo, Katas 참조) 에 대해 팀을 교육하는 것입니다 (경험이있는 TDD 프로그래머가 이러한 워크숍에 참여할 수 있다면 더 좋을 것입니다). 이점을 알게되면 실제 프로젝트에 TDD를 사용할 것입니다. 그러나 그들을 강요하지 마십시오. 그들은 그들이 제대로하지 못할 이점을 보지 못합니다.

코드를 작성하기 전에 디자인 세션이 있거나 디자인 문서를 생성해야하는 경우 세션의 가시적 인 결과로 단위 테스트를 추가 할 수 있습니다.

그러면 코드가 어떻게 작동해야하는지에 대한 사양이 될 수 있습니다. 디자인 세션에서 페어링을 장려하여 사람들이 특정 시나리오에서 어떤 일이 어떻게 작동하고 무엇을해야하는지에 대해 이야기하도록합니다. 예를 들어 null 인수가 주어지면 모든 사람이 수행 할 작업을 알 수 있도록 명시적인 테스트 케이스가있는 가장자리 케이스는 무엇입니까?

제쳐두고 BDD 도 관심이있을 수 있습니다.

테스트를 통과하는 데 필요한 코드 만 작성하기 때문에 TDD가 작성되는 코드가 줄어드는 예를 한두 가지 보여 주면 매력을 찾을 수 있습니다. 작성하지 않은 코드는 유지 보수, 리팩토링 등이 필요하지 않으므로 TDD의 개념을 판매하는 데 도움이되는 "실제 절약"입니다.

시간, 비용, 코드 및 저장된 버그 측면에서 가치를 명확하게 입증 할 수 있다면 판매가 더 쉽다는 것을 알 수 있습니다.

JUnit 테스트 클래스 빌드 시작은 시작하는 방법이며 기존 코드의 경우 시작하는 유일한 방법입니다. 내 경험상 기존 코드에 대한 테스트 클래스를 만드는 것은 매우 유용합니다. 경영진이 이것이 너무 많은 시간을 투자 할 것이라고 생각하면 해당 클래스에 버그가 포함 된 것으로 확인되거나 정리가 필요한 경우에만 테스트 클래스를 작성하도록 제안 할 수 있습니다.

유지 관리 프로세스의 경우 팀을 처리하는 방법은 버그를 수정하기 전에 JUnit 테스트를 작성하여 버그를 재현하는 것입니다.

• 버그가보고되었습니다
• 필요한 경우 JUnit 테스트 클래스 생성
• 버그를 재현하는 테스트 추가
• 코드 수정
• 테스트를 실행하여 현재 코드가 버그를 재현하지 않음을 보여줍니다.

이런 식으로 버그를 "문서화"하면 나중에 버그가 다시 발생하는 것을 방지 할 수 있다고 설명 할 수 있습니다. 이는 팀이 즉시 경험할 수있는 이점입니다.

많은 조직에서이 작업을 수행했으며 TDD를 시작하는 가장 좋은 방법은 쌍 프로그래밍을 설정하는 것입니다. TDD를 아는 다른 사람이 있으면 TDD를 사용하여 실제로 짝을 이룬 프로그래밍을 수행하기 위해 두 사람이 분리되어 다른 개발자와 짝을 이룰 수 있습니다. 그렇지 않다면 다른 팀원들에게 발표하기 전에이 작업을 도와 줄 사람을 교육하겠습니다.

단위 테스트, 특히 TDD의 주요 장애물 중 하나는 개발자가이를 수행하는 방법을 모르기 때문에 시간이 얼마나 가치가 있는지 알 수 없다는 것입니다. 또한 처음 시작할 때 훨씬 느리고 이점을 제공하지 않는 것 같습니다. 그것은 당신이 그것을 잘할 때 실제로 당신에게 이익을 제공합니다. 짝을 이룬 프로그래밍 세션을 설정하면 개발자가 빠르게 배우고 더 빨리 익힐 수 있습니다. 또한 함께 작업하면서 즉각적인 이점을 볼 수 있습니다.

이 접근 방식은 과거에 저에게 여러 번 효과적이었습니다.

TDD의 이점을 발견하는 강력한 방법 중 하나는 성능상의 이유로 일부 기존 기능을 대폭 다시 작성하는 것입니다. 기존 코드의 모든 기능을 포괄하는 테스트 모음을 생성하면 변경 사항이 안전하다는 확신을 가지고 마음의 내용을 리팩토링 할 수 있습니다.

이 경우 디자인 또는 계약 테스트에 대해 이야기하고 있습니다. 여기서 구현 세부 사항을 테스트하는 단위 테스트는 적합하지 않습니다. 그러나 TDD는 구현 전에 작성되어야하므로 정의에 따라 구현을 테스트 할 수 없습니다.

TDD는 개발자가 더 나은 코드를 생성하는 데 사용할 수있는 도구입니다. 나는 테스트 가능한 코드를 작성하는 것이 테스트 자체만큼이나 가치가 없다고 느낀다. 테스트 목적으로 IUT (Implementation Under Test)를 분리하면 코드를 분리하는 부작용이 있습니다.

TDD는 모든 사람을위한 것이 아니며 팀이 선택하도록하는 마법도 없습니다. 위험은 테스트 할 가치가있는 것이 무엇인지 모르는 단위 테스트 작성자가 낮은 가치의 테스트를 많이 작성하여 조직의 TDD 회의론자들을위한 대포가 될 것입니다.

저는 일반적으로 자동화 된 수락 테스트를 협상 불가능 하게 만들지 만 개발자가 TDD를 적절하게 채택하도록 허용합니다. 저는 경험이 많은 TDDers가 나머지를 교육 / 멘토하고 여러 달 동안 예제를 통해 유용성을 "증명"했습니다.

이것은 기술적 변화만큼이나 사회적 / 문화적 변화입니다.