팀원이 TDD를 사용하도록 설득하는 방법 [닫기]

본인은 팀에서 TDD를 사용하는 유일한 사람입니다. 사용하려면 어떻게해야합니까?

내가 뽑을 때 누군가의 코드가 내 테스트를 중단하고 테스트 해야하는 사람이라는 것이 짜증납니다.

github, fork 및 pull 요청을 사용하면이 문제를 해결할 수 있으므로 풀을 수락하기 전에 테스트를 통과해야합니까?

나는 프로젝트 관리자가 아니며 그녀가 그것을 사용하도록 설득 할 수없는 것 같습니다.

내가 보는 방식으로, 테스트에 대해 확신 할 수있는 유일한 방법은 테스트가 유용하다는 것, 즉 테스트 실패가 버그를 찾아 수정하는 데 도움 이된다는 것을 입증하는 것 입니다.

그래도 문제를 설명하는 방식은 그렇지 않습니다. 보기...

... 잡아 당기면 누군가의 코드가 내 테스트를 중단하고 테스트 해야하는 사람입니다.

올바르게 이해하면 테스트를 수정해야합니다. 테스트 실패 가 버그를 찾아 수정하는 데 도움이되는 것처럼 들리지 않습니까? 테스트가 버그를 찾는 데 도움이되지 않는다면 동료에게 설득력있는 위치를 확보하는 것이 매우 약한 것입니다. 그들이 얻을 수있는 것은 무엇입니까? 깨지기 쉬운 테스트 코드의 지루한 수정?

이것은 막 다른 골목처럼 들릴지 모르지만 실제로는 그렇지 않습니다. 최종 목표 (TDD에 대한 확신)는 여전히 타당하지 않습니다. 발견 한 장애물을 제거하는 데 다시 집중하십시오.

이제 귀찮게하는 테스트 실패는 본질적으로 "거짓 경고"입니다. 이는 코드가 아닌 테스트의 버그임을 의미합니다. 테스트를 개선하고 신뢰할 수있는 테스트 설계 방법을 배우는 기회로 활용하십시오. "가짜 경고"를 덜 빈번하게 만들고 테스트 된 코드에서 실제 버그를 쉽게 발견 할 수 있도록 테스트를 수행하십시오.

실제 버그를 발견하면 동료에게 알려주고 문제를 해결하도록 도와주십시오. 이러한 버그가 테스트에서 발견 된 것을 잊지 마십시오. 그렇게하면 동료를 설득 할 수있는 확실한 기반이 될 것입니다.

그것은 가치가 언급이다 시험 디자인 할 때 : 당신이 마지막으로 사용하는 TDD에 동료를 설득 (경우 "예비"단계에서 개발 기술이 대부분의 아마 다시 필요합니다. 생각 해봐 ...

... 시험 중심의 개발이 경험이없는 동료에게 소개되면 어떻게됩니까?

가장 먼저 예상되는 것은 사람들이 크 래피 테스트를 작성하기 시작하고 학습하는 동안 좋은 테스트를 중단한다는 것입니다. 그들이 올바른 방법을 찾도록 돕기 위해서는 훌륭한 테스트 디자인에 대한 확실한 이해가 필요합니다.

테스트에서 찾아 수정 한 모든 오류는 모든 팀원이 학습을 시작할 때 반복해서 반복됩니다. 이런 일이 발생하면 TDD에 대해 긍정적 인 태도를 유지하기 위해 개선 방법을 신속하고 명확하게 설명 할 준비가되어있는 것이 좋습니다 .

Test Driven Development 의 사용을 장려하고 싶을 때는 Cyber-Dojo를 실행했습니다 . 이러한 종류의 연습에서는 코드 자체가 아니라 코드 작성 프로세스 에 중점을 둡니다 .

우리는 오후를 같은 쌍의 카타를 반복하면서 서로 다른 조건으로 반복하여 보냈습니다. 우리는 모든 그룹이 동시에 하나의 운동을하는 것으로 시작했습니다. 이것은 기준을 제공했습니다.

그런 다음 TDD의 기본 원칙 중 일부를 논의하고 모두가 파트너를 변경하고 동일한 카타를 반복하도록했습니다. 동일한 kata를 반복하여 코드 생성을 강조하지 않고 대신 테스트 케이스 이름 지정 프로세스와 Red / Green 사이클에 사람들을 집중 시켰습니다.

그런 다음 카타를 다시 반복했지만 대략 10 분마다 각 그룹의 한 사람이 다른 그룹으로 이동하여 요즘 우리가 자주 찾는 유동적 인 팀 환경을 시뮬레이션합니다.

마지막 반복에서는 두 파트너가 10 분마다 다른 그룹으로 변경되었습니다. 이것은 TDD를 사용하면 한 팀에서 완전히 다른 팀으로의 핸드 오버조차도 너무 고통 스러울 필요는 없다는 것을 입증하는 데 도움이되었습니다. 프로젝트는 모든 작업에서 하나의 빨강 / 녹색 사이클이어야하기 때문입니다.

흥미로운 것은 세션 전에 TDD를 한 사람이 거의 없었지만, TDD에 대한 지식이 카타를 통해 최종 반복 될 때까지 빠르게 퍼져 나갔으며, 대부분의 사람들은 TDD 방식으로 생각하고 있었거나 적어도 왜 그 이유를 이해할 수 있었는지 도움이 될 수 있습니다.

사람들은 일반적으로 오후가 재미 있고 유익한 정보라고 말했으며 현재 직장에서 사이버 도조를 사용하는 다른 방법을 찾고 있습니다.

Jon Jagger가 작성한 Cyber-Dojo 는 이러한 종류의 운동에 매우 효과적입니다. 그것은 수행하기위한 웹 기반 통합 환경을 의도적 연습 의 TDD를 팀 역학에 대한 학습. 사람들이 TDD 과정에 집중하는 데 도움이되도록 특별히 선택된 카타가 많이 있습니다. 또한 Python 및 Ruby에서 Java 및 C ++에 이르기까지 다양한 언어를 지원합니다.

가장 좋은 점은 카타를 한 후에 돌아가서 참여하는 각 그룹의 빨강 / 녹색 진행 (또는 * 8 '아님)을 볼 수 있다는 것입니다. 그것의 신호등은 TDD 방식의 프로세스가 작동하는 방법을 시각화하는 좋은 방법입니다.

자신의 CyberDojo 서버를 원한다면 전체 프로젝트 를 github에서 찾을 수 있으며 거기에 연결된 턴키 Linux 어플라이언스 가상 머신도 있습니다. 즉, 이미 VMware 플레이어 또는 VirtualBox가 설치되어 있다고 가정하면 몇 분 동안 기기를 다운로드하십시오!

그들이 TDD에 저항한다면 괜찮습니다. 많은 사람들 (나 자신을 포함하여)은 먼저 단위 테스트 작성에 문제가 있습니다.

그러나 단위 테스트가 전혀없고 단위 테스트가 중단되는 문제에 대한 질문을 제기해야합니다. 단위 테스트는 가능한 많은 버그를 방지하고 코드 리팩토링을 허용하는 안전망입니다. 더 높은 코드 품질과 더 깨끗한 코드에 대해 설명하십시오.

TDD 사용의 장점을 설명하는 비디오를 찾아 회의에 보여주는 것이 가장 좋을 것 같습니다.

그녀가 듣기를 거부한다면, 당신은 그녀의 누군가에게 가려고 시도 할 수 있지만, 상사가 너무 고집이 있다면 그렇게 똑똑하지 않을 수 있습니다.

사람들이 습관을 바꾸도록 설득하는 것은 정말 어렵지만 다음은 시도해 볼 수있는 몇 가지 사항입니다.

• 다른 개발자와 이야기하고 왜 TDD가 좋은 생각이라고 생각 하는지 설명하십시오 .
• 제한된 시간 동안 시도해 보도록 (또는 적어도 일부) 설득하십시오.
• 팀으로 일하기위한 최소 요구 사항을 설정하십시오. 반드시 TDD를 수행 할 필요는 없지만 단위 테스트에 실패한 코드를 확인해서는 안됩니다. 이것은 TDD를 사용하도록 설득하는 것보다 별도의 문제이며 해결하는 것이 훨씬 중요합니다.
• 경영진에게 TDD 시험 기간을 시행하도록 설득하십시오. 이것이 왜 좋은 습관인지, 그리고 그것이 회사의 시간과 돈을 어떻게 절약 할 것인지에 대한 증거를 제공 할 준비가되어 있어야합니다.

이 중 어느 것도 작동하지 않으면 다른 곳에서 작업하는 것을 고려할 수 있습니다. 당신의 인생이 훨씬 쉬워 질 다른 회사들이 많이 있습니다.

여기에는 약간 다른 두 가지 문제가 있습니다. 사람들이 TDD를 수행하도록하는 것과 테스트를 중단하는 사람들.

첫 번째 문제에 대해 잘 모르겠습니다. 개인적으로 인공 작업 방식으로 모든 유형의 개발에 적합하지는 않습니다. 나는 단위 테스트를 잘하는 것이 전부이지만 코드를 작성하는 동안 아이디어가 항상 바뀌기 때문에 코드를 먼저 작성하고 테스트하는 것이 더 효율적이라는 것을 알았습니다. 테스트를 작성하는 것도 시간 낭비입니다. 초기 (IMO).

두 번째 문제에서는 유닛 테스트가 체크인시 실행되도록 프로젝트를 설정하여 다른 개발자가 테스트를 마친 것을 선택할 수밖에 없습니다.

다른 많은 "X가 Y 방법 / 기술을 사용하도록 설득해야하는 방법"에서 말했듯이 대답은 항상 같습니다.

그것을 사용하고 더 나은 (측정 가능한) 결과를 얻으십시오. 그런 다음 다른 사람들이 알아 차리십시오.

기존 프로젝트에서는 그렇지 않습니다. 들여 쓰기 스타일을 싫어하기 때문에 중괄호가 레거시 코드에 배치되는 방식을 변경하는 것과 동일합니다.

좋은 조언이 많이 있습니다. 그리고 지금, 조금 더 ...

한 번에 하나의 Luddite 로 마음과 생각 (WHAM)을 얻어야 합니다 . 목구멍을 강요하는 것을 잊어라. 무한한 (그런 것에 대해 유감스러운) 기간 동안 많은 물건 교훈. 결국 당신은 비판적인 집단을 맞을 것이며, "올바른"사람을 설득 할 것입니다.

TDD에 대한 지속적이고 일관된 열정과 소명은 WHAM 캠페인에서 매우 중요합니다.

당신은 설정해야합니다 가르침을받을만한 순간에 테스트 파괴 및 코드 변경, 당신의 공동 코더에 대한 중요한 교훈을. 개인적으로 만드십시오. IE 그들은 평균 이상의 깨끗한 코드를 제공한다는 평판에 관심이 있습니까? 통합 테스터들이 현실 점검을했기 때문에 현재 늦었 던 코드에 대해 경영진이 걱정 하는가? Jack은 어려운 코드를 수정하고 싶지만 부작용을 두려워합니까?

코더로 인한 버그를 잡는 것으로 테스트 중단 의 좋은 예를 수집하십시오 . 코더는 테스트를 관련없는 코드에 대한 불필요한 작업으로 간주합니다. 그들은 시험이 방금 그들의 주장을 다루었 음을 이해해야한다.

전역 적으로 영향을 미치는 코드 (일부 간단한 유틸리티 방법)를 찾고 몇 가지 테스트를 작성한 다음 테스트가 애플리케이션 전체에서 지진에 대한 두려움없이 변경을 허용한다는 것을 보여줍니다. 그리고 나는 감정적 인 문제도 강조하는 것을 의미합니다!

간단한 코드 정리 시간 예제 (예 : 프로덕션으로 전달)를 수집 하고 테스트 코딩을위한 추가 노력에도 불구하고 더 빠르게 고품질로 작업을 수행 했음을 보여줍니다 .

경고 : TDD는 잘못된 OO 설계 및 코딩을 치료할 수 없으며 극복 할 수 없습니다 (그러나 노출 될 수 있음). Luddites가 무능하다고 테스트 코드 노력을 비난하지 마십시오.

관리자를 설득하기 위해 다시 시도합니다. 당신이 쓴 것에서, 나는 당신이 당신의 팀원들이 그녀의 뒤에서 TDD를하도록 설득 할 수 있다고 생각하지 않습니다.

그녀의 언어를 말해야합니다. 관리자는 기술에 깊은 인상을받지 않지만 비즈니스 언어를 이해합니다.

• 테스트는 수동 테스트 (레일 콘솔을 사용하여 로컬에서 버그를 재생하려고 시도하는 대신) 대신 테스트를 자동으로 실행하기 때문에 개발 중 시간을 절약 할 수 있습니다.

• 테스트는 애플리케이션을 유지 관리하는 동안 무언가를 변경할 때마다 쉽게 버그를 감지 할 수있는 많은 시간을 절약합니다. 테스트에는 초기 투자 비용이 더 많이 필요하지만 장기적으로 비용을 지불한다고 설명합니다 (좋은 테스트 유지 관리는 일반적으로 빠르고 쉽습니다)

• 그리고 여분의 시간으로 무엇을 할 것인가? 멍청한 물건을 만들어 돈을 버는 법 :)

프로그래머에 관해서는 다음과 같은 주장을 시도해보십시오. "TDD의 유무에 관계없이 코드를 테스트하고 있습니다. 자동화 대신 수동으로 코드를 작성하십시오. 똑똑한 개발자는 최대한 많은 것을 자동화합니다. "

마감일이있는 실제 프로젝트에서 사람들은 자신이 알고있는 작업을 수행하는 데 집중하려고합니다. 그것은 단지 인간의 본성입니다. 그리고 TDD를 배운 적이 없다면이 상황에서 그녀와 동일 할 것입니다. 나는 그것을 guarnatee.

가비지 수집은 왜 RAII를 좋아하고 배우고 살고 있지 않습니까? 어떻게 자동 메모리 관리를 유지하면서 파일, 연결 등과 같은 일반적인 리소스에 대해 구식 관리를 유지할 수 있습니까? RAII는 작업이 필요한 마감일이있을 때 알지 못하고 이해하며 사용할 시간이없는 기술이기 때문입니다.

RAII를 사용하지 않으며 현재 프로젝트에서 RAII를 배우고 기꺼이 배우지 않을 것입니다. TDD를 배우고 이해하지 않는 동료와 동일합니다.