“코드가 더 많을수록”단위 테스트를 사용하지 않는 동료

동료는 단위 테스트를 사용하지 않고 빠른 테스트를 선택하여 사용자에게 전달하고 모든 것이 제대로 게시되면 게시됩니다. 말할 필요도없이 몇 가지 버그가 발생합니다.

단위 테스트 사용에 대해 생각해야한다고 언급했지만 더 많은 코드를 작성해야한다는 사실을 알게되면 그녀는 모두 반대했습니다. 이렇게하면 무언가를 수정하고 출력이 동일한 지 확실하지 않습니다. 특히 코드가 스파게티이므로 기회가 생길 때 리팩토링하려고합니다.

그래서 나에게 가장 좋은 방법은 무엇입니까?

그녀는 단위 테스트의 이점을 알지 못 하므로 변경해야합니다.

• 그녀의 인식.

당신뿐만 아니라 그녀의 작품을 향상시킬 것임을 그녀에게 증명해야 할 것입니다. 어려울 것입니다. 그녀는 변화를 두려워한다면 찾을 수있는 모든 부정적인 측면에 집중하려고 노력할 것입니다.

모든 혜택에 대해 그녀와상의하고 모든 반대 의견을 경청 할 수 있습니다. 대화를 시작하기 전에 그녀가 대화를 시작하기 전에 기다리십시오.

자신을 준비하려면 P.SE 또는 Google에서 관리 또는 개발자가 단위 테스트에 대해 걱정하고 동료와 토론하는 동안 사용할 답변을 컴파일하는 모든 사항을 찾아야합니다.

그녀의 말을 듣고 그녀의 일을 향상시킬 수 있다는 증거를 제공하면 많은 도움이 될 것입니다. 당신은 그녀의 의견에 관심이 있다는 것을 증명하고, 상황을 분석하고 결국 그녀의 마음을 바꾸는 데 필요한 모든 데이터를 그녀에게 제공합니다.

단위 테스트 작성 (말하지 마십시오)

문제가 해결 될 때까지 기다렸다가 2 일 동안 수동 테스트를 한 다음 단위 테스트를 꺼내고 3 초 안에 버그를 찾으십시오.

엄호 해 ...

그렇지 않으면 수동 작업을 자동화하면 모든 프로그래머에게 호소해야합니다.

그래서 그녀는 수동으로 덜하는 "더 많은 코드를 작성하지"않습니다.

자동화 된 테스트의 요점 중 하나는 반복성 입니다. 수작업으로 빠른 테스트를 수행하는 경우 단위 테스트와 동일하게 작성하는 것보다 빨리 수행 할 수 있습니다 (최소한 단위 테스트 초보자의 경우 단위 테스트에 경험이있는 사람은 테스트를 매우 빠르게 수행 할 수 있음).

그러나 내일 또는 다음 주에 코드가 약간 (또는 크게) 변경되면 어떻게됩니까? 변경 사항이 없는지 확인하기 위해 동료가 변경 후마다 동일한 수동 테스트를 계속 반복해서 반복 하시겠습니까? 아니면 "코드와기도"를 선호할까요?

코드가 많이 변경 될수록 단위 테스트가 초기 투자를 더 많이 상환합니다 . 테스트가 실제로 버그를 잡지 않아도 긍정적 인 측면을 얻는 데 시간이 오래 걸리지 않습니다. 그러나 그들은 정기적으로 그렇게합니다.이 시점에서 그들은 귀중합니다. 그리고 일단 누군가가 안전하다고 느끼고, 성공적인 단위 테스트 실행이 제공하는 코드에 대한 확신을 가지면, 일반적으로 되돌릴 수 없습니다.

그녀가 확신이 있지만 새로운 영역으로 모험하기를 두려워하는 경우, 첫 단위 테스트를 함께 작성하기 위해 페어 프로그래밍 세션을 제공하십시오 . 테스트하기가 어렵지 않지만 테스트 할 가치가있는 복잡한 클래스를 선택하십시오.

그러나 그녀가 확신하지 못하면 어려운 사실을 수집해야 할 수도 있습니다 . 그러한 사실은

• 자신이 작성한 코드의 결함률
• 그녀의 코드에 대해 일련의 단위 테스트를 작성하고 발견 된 버그를 문서화합니다.

그러한 데이터를 수집 한 다음 결과를 공손하게 보여주십시오. 이것들이 여전히 그녀를 설득하기에 충분하지 않으면, 문제를 논의하고 수집 된 증거를 경영진과 공유해야 할 수도 있습니다. 그것은 최후의 수단 일 뿐이지 만 때로는 다른 방법이 없습니다.

코드의 최악의 비트에 대한 기본 테스트 범위를 작성하고 해당 테스트를 기반으로 코드를 래 팩터링 한 다음 지속적인 빌드에서 단위 테스트를 수행하면 생산성이 향상됩니다. 단일 개발자가 복음을 전하지 않고 고용주가 지시 할 때 변경이 더 쉬워집니다.

이것을 올바르게 표현하는 방법을 모르지만, "기회를받을 때"코드를 리팩토링하는 경우 ... 아마도 "그녀의 사업"에 참여한 것에 대한 약간의 관용구 일 것입니다. 열린 마음으로 당신의 말을 듣지 않을 것입니다. 내 경험상 사람들은 자신이 한 일에 푹 빠지게됩니다.

악마를 옹호하려면 : 그녀는 요점이 있습니다. 나는 보통 다음과 같이 넣습니다.

자동 테스트는 더 많은 코드로 많은 코드의 문제를 해결합니다.

이론적 해석:

• 오류 속도와 OO 지표의 상관 관계에 대한 연구 , 헤드 라인 결과 : "더 이상 우리가 결함 경향성과 관련이 공부 메트릭 없음 [클래스] 크기 조절 후" . (연구는 클래스 크기에 대해 논의합니다.이 효과는 코드베이스의 크기까지 확장됩니까? 아마도 제 생각에는 )
• 경험적으로 대규모 프로젝트는 천천히 진행되는 경향이 있습니다. "새 프로젝트에서 5K 라인 하룻밤"대 "큰 라인에서 10 라인 / 일". 이것이 코드베이스의 크기에 따라 증가하는 "저항"을 나타내는가?
• 우리는 항상 "최고의 언어는 없으며 문제에 달려 있습니다"라고 선언합니다. 핵심 요구 사항 중 하나는 선택한 언어로 문제 엔터티 및 작업을 쉽게 모델링하는 것입니다. 그것은 당신의 문제를 표현하는 것이 더 정교한 언어를 선택하는 것이 더 나쁘다 는 것을 제안하지 않습니까? 그리고 그것이 코드베이스의 최종 크기와 다시 상관되지 않습니까?

이제, 그것에 대해 쉽게 반박해야 할 몇 가지 주장이 있습니다. 내가 생각할 수있는 것들을 다룰 게 :

• 크기 대 단순성 : 물론 코드를 더 짧고 나쁘게 만들 수 있습니다. 그러나 이것은 다른 간결성 대 단순성 비율로 코드베이스를 비교할 때만 문제가됩니다 . 토론을 위해이 요소를 어떻게 든 제어 할 수 있다고 가정 할 수 있습니다.

• 단위 테스트는 종속성을 줄 이도록 압력을 가하며, Depencies를 줄이면 코드 크기 문제를 줄일 수 있다는 점에 경험적으로 동의합니다. 그러나 생산 코드 단위 간의 종속성을 줄이면서 테스트와 장치 자체 간의 연결을 도입합니다.

TL; DR : 단위 테스트가 나쁘다고 주장하지 않습니다. 나는 묻습니다 : 코드의 양과 관련된 테스트가 손상되는 손익 분기점이 있습니까?

난 당신이 어려운 입장에 있다고 생각합니다. 사람들이 단위 테스트를 작성하지 않거나 유지하기 어려운 끔찍한 단위 테스트를하지 않는 팀에 근무했습니다. 그러나 모든 사람들은 단위 테스트가 좋다는 사실을 알고있었습니다.

따라서 팀의 단위 테스트 스위트를 좋은 품질로 만드는 것은 오랫동안 힘든 길이었습니다. 상황을 개선하고 아이디어를 전달하며 경험을 공유 할 수있는 곳을 항상 주시하십시오.

반면에, 당신은 심지어 혜택을 깨닫지 못한 개발자가 있습니다. 그리고 스파게티 코드도 코딩합니다. 이 특별한 경우에 가장 중요한 이유 중 하나는 좋은 단위 테스트를 작성하면 느슨하게 결합 된 디자인이 필요하다는 것입니다. 따라서 그녀가 테스트를 작성하게함으로써 장기적으로 "실제"코드를 향상시킬 수 있기를 바랍니다.

그러나 결국 팀 결정이라고 생각합니다 (팀에 몇 명인지는 모르겠습니다)? 팀이 잘 커버하는 단위 테스트 스위트가 있어야한다는 합의에 도달 할 수 있다면, 모든 사람이 환경을 준수하고 경험을 공유하며 팀이 함께 성장할 수 있도록해야합니다.

그러나 팀이 단위 테스트를 작성해야한다는 합의에 도달하지 못하면 다른 개발 팀과 협력 할 것을 제안합니다.)

그녀는 보스입니까?

만약 그렇다면 ... 기본적으로 "예방의 온스는 치료의 가치가 있습니다"의 선을 따르는 혜택을 그녀가 확신 할 수 없다면 당신은 다소 고집이납니다. 버그가 발생합니다. TDD는 일관된 출력을 만들어이를 완화시킵니다.

그녀는 보스가 아닌가?

근무하는 코딩 표준은 무엇입니까? 그녀는 왜 스파게티 코드를 뿌릴 수 있습니까? "TDD에 시간을 조금 더 투자하면 버그에 더 적은 시간을 할애 할 것"이라는 상사에게 비즈니스 사례를 제시하십시오. 비즈니스 사례로 변경을 시행 할 수있는 사람을 설득하십시오.

TDD가 시간과 $$ MONEY $$를 절약 할 수있는 문서 사례.

이 버그 자체가 나타났습니다. 생방송하기 전에 잡혔을 것입니다. 2 시간 동안 예방하면 10 시간 동안 치료할 수있었습니다. 여기와 여기와 여기에서 일어난 일입니다. 10 시간의 근무 시간으로 회사는 30 시간을 절약 할 수있었습니다. 그게이 돈이야

이것은 무언가를 수정할 위치에 남겨 둡니다.

왜?

그들은 문제를 일으켰습니다. 그들은 그것을 해결해야합니다.

어떤 관리자가이 문제를 허용합니까? 왜 다른 사람의 버그 코드가 문제입니까?

동료 와 관리자가이 문제를 해결하고 있습니다. 그리고 그들의 혼란을 정리함으로써 당신은 기꺼이 활동적인 참가자입니다.

품질이 좋지 않다고 느끼지 않으면 아무것도 바뀌지 않습니다.

그녀는 정확합니다. 단위 테스트는 "더 많은 코드"입니다.

그러나 프로그램이 어떻게 작동하는지 확인하기 위해 작성해야 할 코드가 더 많습니다. 시간 낭비가 아닙니다. 핵심 구성 요소만큼이나 시스템의 일부입니다.

그녀에게 도전하십시오 :

1. 코드에 익숙하지 않은 사람이 무언가를 변경하면 어떻게됩니까?
2. 경험이없는 사람이 무언가를 변경하면 어떻게됩니까?
3. 시스템 유지 관리 비용은 생성하는 데 걸리는 시간으로 측정되지 않습니다. 장기 제안입니다. 총 소유 비용에 대해 생각해보십시오.
4. 그녀의 추정 (코딩이 시작되기 전에 필요한 경우)에는 단위 테스트 작성 요구 사항이 포함되어야합니다. 기업인은 단위 테스트를 직접 요구하는 요구 사항을 만들지 않지만 암시 적 품질 요구 사항이 있으며 향후 변경 사항에 버그가 수반되지 않거나 동일한 프로그래머가 소스를 변경해야합니다.

현재 프로덕션 코드를 수행하고 TDD가 아닌 단위 테스트를 수행하는 것으로 말하면 현재 위치에 적합하지 않은 것 같습니다 (일부 프로젝트에서 TDD를 수행했지만 다른 도구로 간주합니다. 은총 알이 아니라 ol 'bag) ...

어려운 판매 일 수 있습니다. 단위 테스트에서 동료를 판매 할 수 없었습니다. 생산 코드보다 단위 테스트 코드에서 더 많은 오류가 발생하는 경향이 있음을 알고 있습니다. 따라서 단위 테스트 코드를 수정하는 데 많은 시간을 소비해야하는 것은 약간 실망 스럽지만 ... 코드를 수정하면 좋은 보험입니다. 가장자리 조건을 자동으로 테스트하는 좋은 방법입니다.

단위 테스트를 직접 작성하여 단위 테스트가 얼마나 도움이되는지 보여줍니다.

성 프란치스코가 한 번 말한 것처럼 "항상 전파하십시오.

그녀가 코드에서 단위 테스트를 사용하고 단위 테스트로 버그를 더 빨리 해결할 수 있다고 생각하면 마음이 바뀔 수 있습니다. 그러나 그렇지 않을 수도 있습니다.

결과에 상관없이, 그녀는 당신이 원하지 않는 무언가를 그녀에게 밀고있는 것으로 보지 않습니다. 그것은 당신이 바꾸어야 할 것입니다, 당신이 모범으로 이끌지 않는다는 인식.