동료들에게 단위 테스트 (및 일반적인 테스트) 개념을 소개하고 싶습니다. 지금은 전혀 테스트가 없으며 실제로 UI를 통해 작업을 수행하여 원하는 결과를 확인하여 테스트합니다. 당신이 상상할 수 있듯이, 코드는 정확한 구현과 매우 밀접하게 연결되어 있습니다. 심지어 클래스에 있어야하고 시스템 전체에서 재사용되어 코드를 메소드에 복사하여 붙여 넣을 수 있습니다.

변경된 요구 사항으로 인해 이전에 작성한 모듈을 수정하라는 요청을 받았으며 상당히 느슨하게 결합되었습니다 (원하는 만큼은 아니지만 다른 많은 개념을 도입하지 않고도 얻을 수있는 최선의 방법). 나는 예상대로 작동하고 테스트가 어떻게 작동하는지 보여주는 "증명"하기 위해 수정 된 코드와 함께 단위 테스트 스위트를 포함하기로 결정했다. 일부 코드가 이미 작성되었으므로 실제 TDD를 따르지 않지만 새로운 코드를 작성하기 위해 TDD 개념을 따르기를 바랍니다.

필자는 필자가 상호 작용할 부분이 이미 시스템에 존재하기 때문에 코드를 작성하는 데 하루나 이틀 이상 걸리는 이유를 물을 것입니다. 코드를 확인하면이 "Tests"프로젝트가 무엇인지 물어볼 것입니다. 테스트의 기본 사항을 설명 할 수는 있지만 다른 사용자가 이해할 수있는 방식으로 실제 이점을 설명 할 수는 없습니다 (테스트에서 앱을 직접 실행해야한다고 생각하기 때문에 실제 UI가이 기능의 작동 여부를 결정하는 데 중요한 경우가 종종 있기 때문에) "아니요). 그들은 느슨한 결합의 개념을 이해하지 못합니다 (아무것도 느슨하게 결합되어 있다는 사실에 분명히 분명합니다. 내가 작성한 코드 외부에는 인터페이스조차 없습니다), 그래서 그것을 이익으로 사용하려고하면 아마 "어?" 몇 가지 기존 모듈을 재 작업하지 않고 원하는만큼 느슨 할 수 없으며 아마도 "프로그래밍"이 아닌 시간 낭비로 볼 수있는 일종의 IoC 컨테이너를 소개 할 것입니다.

누구든지이 코드를 가리키고 "우리는 단위 테스트 작성을 시작해야합니다"라고 말하는 방법에 대한 제안이 있습니까? 내 것이 나쁘지 않다 ) 또는 실제 가치를 추가하지 않는 시간 낭비처럼 보이게하지 않으면?

동료들에게 단위 테스트 (및 일반적인 테스트) 개념을 소개하고 싶습니다.

나는 개념적인 측면이 아닌 실제적인 측면에서 시작하는 것이 낫다고 생각합니다. 물론, 일상적인 토론 중에 동료 및 / 또는 경영진이 단위 테스트에 대해 듣고 싶어한다는 사실을 발견하면 더 좋습니다. 웹에서 구체적인 경험 / 증거를 찾아 내거나 간단한 교육 등을 할 수 있습니다. 그러나 당신이 묘사 한 바에 따르면, 팀원 들이이 이상한 새로운 아이디어에 크게 열리지 않는 것처럼 들립니다.

그런 상황에서 나는 누군가에게 너무 많은 것을 설명하지 않고 작은 단위 테스트를 작성하기 시작합니다. 모든 코드를 철저히 다루지 않고 코드를 변경할 때마다 두 개를 추가하십시오 (시간이 많이 걸립니다). 이상적으로, 균형이 잡히면 단위 테스트를 작성할 때까지 이미 상당한 테스트 스위트와 몇 가지 구체적인 결과가 표시 될 수 있습니다. 지난 주 변경에 의해 도입되었으며, 그렇지 않으면 품질 관리 / 생산으로 넘어 갔을 수 있습니다 "). 그것은 심각한 개발자에게 테스트의 가치를 증명할 것입니다.

그 후, 나는 단위 테스트의 장기적인 이점을 설명하기에 좋은 위치에 있습니다.

• 코드가 언제 어디서나 즉시 자동으로 작동한다는 것을 증명합니다.
• 리팩토링에 대한 확신을 제공하여 설계를 개선하고 유지 보수성을 향상시킵니다.
• 문제가 발생하면 별도의 QA 부서에서 버그를 발견 한 경우 며칠 또는 몇 주 동안의 대기 시간과 달리 단위 테스트를 통해 (거의) 즉각적인 피드백을 제공합니다. 일반적으로 단기 메모리에서 오랫동안 삭제 된 코드에서 몇 시간 / 일 동안 디버깅하는 대신 초 단위로 버그를 수정할 수 있습니다.

이 관련 스레드 : 자동화 된 단위 테스트, 통합 테스트 또는 승인 테스트를 참조하십시오 .

그리고 이전의 SO : 단위 테스트 란 무엇입니까?

두려움없이 리팩터링

약간 다른 각도로 TDD를 사용하면 "두려움없이 리팩터링"할 수 있으며 이는 팀을 판매 할 수있는 주요 이점입니다. 개발자가 스스로 말하지 못하게합니다.

• "이 코드를 깨뜨리지 않기 때문에이 코드를 건드리고 싶지 않습니다."
• "어떻게 작동하는지 모르겠 기 때문에이 코드에 대한 새로운 기능을 작성하고 싶지 않습니다."
• "비밀하게, 나는 그 코드를 두려워한다"

더 많은 것을 할 수는 있지만 TDD의 밥 삼촌 과 TDD의 마틴 파울러 와 같이 잘 덮여 있습니다.

의존성

아, 하나 더 추가하겠습니다. TDD가 어떻게 의존성을 깔끔하게 처리 할 수있는 좋은 디자인을 강요하는지 보여줍니다.

Bob : "아 c % ^ p! 보스들은 방금 우리 모두에게 MS SQL Server 2008을 사용하도록 강요했습니다."Jane : "괜찮습니다. 데이터 소스와 DAO 클래스를 DI로 인해 피해를 입었 기 때문에 TDD가 장려하게되어 기쁩니다. 우리를 그 길로 내려가십시오. "

자동화 된 테스트가없는 소스 코드에서 작업하는 동안 많은주의를 기울여 작업해야하며 변경 사항이 기존 기능을 손상시키지 않는다는 확신을 가지려면 더 많은 검토가 필요합니다.

자동화 된 테스트 사례가 있으면 결과는 더 빠르고, 자신감 있고, 두려움없이 개발 될 것입니다 (버그 수정, 향상 또는 리팩토링 일 수 있음).

수학을

• t _mt = 생각할 수있는 모든 것을 수동으로 테스트하는 데 필요한 시간
• t _wt = 테스트 작성에 필요한 시간

• k = 새 코드를 공개하기 전에 모든 것을 테스트해야 할 횟수

  만약 (t _wt <t _mt ) 또는 (t _wt <(k * t _mt ))라면 당연한 일입니다. 테스트를 작성하면 개발 속도가 빨라집니다.

그렇지 않으면 비율 (t _wt / (k * t _mt ))을보십시오. 매우 큰 경우 다른 기회를 기다리십시오. 그렇지 않으면 회귀 테스트 이점으로 정당화됩니다.

참고 :이 시점에서 단위가 아닌 기능 만 테스트 할 것을 제안 합니다. 리팩토링 할 때 단순한 단위 테스트보다 높은 값으로 작업하는 것이 정당화되고 이해하기가 훨씬 쉬울 것입니다.

참고 2 : 시간이는 데 걸리는 실행 테스트를 중요하지 않습니다 그들은 자동화 있기 때문에. 테스트 실행 시간이 너무 길어 마감 시간을 놓치게 하지 않는 한 테스트를 실행하는 동안 다른 생산적인 작업을 수행 할 수 있습니다 . 드문 일입니다.

당신이 마이크로 소프트 가게 경우 한 가지 제안 : 단위 테스트 또는 느슨한 couping 가장 좋은 방법으로 (나는 확실히의 여러 인스턴스가하고 권장 MSDN에 대한 몇 가지 문서를 찾을 수 이 충돌이 경우에) 및 지점.

그것은 일을하는 끔찍한 방법처럼 들릴 수 있지만, '모범 사례'라는 용어를 사용하면 특히 경영진에게 먼 길을 걸리는 것으로 나타났습니다.

항상 권장 하듯이, 모범 사례를 알고 있다면이를 환경에 부드럽게 도입하는 가장 좋은 방법은 물론 직접 시작한 다음 그 과정을 따라가는 것입니다. 일부 동료는 이점을보고 데리러

여기서 키워드는 혁명이 아니라 진화입니다.