동료들이 단위 테스트를 작성하도록 동기를 부여하는 방법? [닫은]

우리는 약 5 년 동안 생산 된 대형 제품을 연구하고 있습니다. 코드베이스가 작동 중입니다. 실제로는 좋지 않지만 작동합니다. 새로운 기능은 생산에 투입되고 소규모 QA로 테스트됩니다. 버그는 수정되었습니다. 그러나 저 외에는 단위 테스트를 작성하는 사람이 없습니다. 이 특별한 버그 (테스트 사례)가 다시는 발생하지 않도록 단위 테스트를 작성하여 "트래킹"기능을 사용하는 사람은 없습니다.

경영진과 이야기를 나 ve습니다. 개발자와 이야기했습니다. 회사 전체의 모든 사람과 이야기를 나 ve습니다. 모두가 말합니다. "그렇습니다. 더 많은 단위 테스트를 작성해야합니다!" 약 1 년 전이었습니다. 그 이후로 저는 사전 커밋 코드 검토 ( Gerrit )와 지속적인 통합 ( Jenkins )을 도입했습니다.

나는 단위 테스트에 관한 회의를 열었고 단위 테스트 작성의 이점도 보여주었습니다. 그러나 아무도 관심이없는 것 같습니다.

Q1 : 동료 동료들이 단위 테스트를 작성하도록 동기를 부여하려면 어떻게해야합니까?

Q2 : 개인 코드 품질 표준을 준수하기 위해 어떻게 동기를 유지합니까? (때로는 정말 실망 스럽습니다!)

추신 : 몇 가지 실망스러운 사실 (1 년 만에 도달) :

• 총 단위 테스트 : 1693
• 총 "단위 테스트 예": 약 50
• 나에 의해 수행 : 1521

편집 : 너무 많이 기대하고 있습니까? 그것은 나의 첫 직장이며 최선을 다하려고 노력하고 있습니다.

편집 2 : 모든 답변을 바탕으로 작은 점검표를 작성했습니다. 나는 개인적으로 두 명의 개발자와 이야기했고 우리는 훌륭하고 정직한 대화를했습니다.

그들 중 하나는 Telastyn이 말한 것처럼 단위 테스트에 정말 불편하다고 말했습니다. 그는 "보다 전문적인"사람이되고 싶지만 킥 스타트가 필요하다고 말했습니다. 또한 모든 개발자 (약 9-11 세)와의 단위 테스트 회의는 훌륭했지만 너무 혼잡했습니다. Meh. 나를 위해 몇 가지 비평가가 있지만, 그로부터 배울 것입니다. (tdd kata 회의에 관한 아래 답변을 참조하십시오!)

다른 하나는 단위 테스트 작성에 관심이 없다고 말했습니다. 그는 그의 일이 월급에 충분하다고 생각합니다. 그는 더 많은 노력을 기울이고 싶지 않습니다. 나는 말이 없었습니다. 전형적인 9-5 "작업자".

다음 주에는 다른 개발자들과 이야기하겠습니다.

큰 답변과 지금까지 지원해 주셔서 감사합니다. 정말 감사! 나는 많은 것을 배웠습니다, 대단히 감사합니다!

TDD에 대한 이야기가 효과가 없다는 것을 알았습니다. 사람들은 원시 결과 를보고 싶어합니다 . " 테스트를 작성하면 개발 시간이 단축 될 것"이라고 말하는 것이 가장 사실이지만, 누군가를 확신 시키기에는 충분하지 않을 수 있습니다.

나는 비슷한 위치에 있었으며 (잘, 당신만큼 나쁘지 않은) 사람들이 내 코드 작업을 시작했을 때 자체적으로 해결되었습니다 (참고 : 내 코드는 단위 테스트되었지만 다른 사람들은별로하지 않았습니다). 무언가가 작동을 멈췄을 때, 현지 조사 후 자연스럽게 추적 조사를 하여 이유가 무엇인지 물었습니다 . 그런 다음 우리는 앉아서 단위 테스트를 수행하고 무슨 일이 있었는지 보았습니다. 테스트가 통과되면 대부분의 시간 문제는 테스트되지 않은 새로운 코드에있었습니다. 그렇지 않은 경우, 테스트는 일반적으로 문제를 발견 할 수있었습니다 (또는 적어도 올바른 방향으로 우리를 가리킴). 우리는 버그를 수정하고 테스트가 다시 시작되었으며 모두가 행복했습니다.

간단히 말해서, 이와 같은 몇 가지 상황이 발생하고 2 명의 개발자가 TDD / 테스트 애호가가되었습니다 (아직 더 갈 것이지만 유망한 것으로 보입니다).

조언에 관해서는 TDD kata와 함께 갈 수 있습니다. 간단한 작업은 반대로 테스트 첫 번째 방법을 사용하여 구현하는 어떤 시험 . 작업이 얼마나 복잡한 지에 따라 테스트가 아닌 접근 방식은 일반적으로 속도가 느려 야합니다. 특히 점진적으로 필요한 변경 사항이있는 경우 :

• 로이의 문자열 계산기
• 은행 OCR

편집 : OP의 댓글이 나를 자신의 처분에 더 강한 인수 거기 깨닫게 - 회귀 일명 돌아 버그 . 이러한 상황은 유익한 단위 테스트가 가능한 방법을 보여주는 완벽한 예입니다. 숫자를 좋아하는 사람들-내가 말했듯이 "단위 테스트가 좋다" 고 말하는 것은 설득력이 없지만 다음과 같은 데이터를 배열하는 것은 확실합니다.

• 기능을 구현하는 데 소요되는 시간 (테스트가 작성되지 않았습니다.
• TDD와 기능을 구현하는 시간 추정 (또는 후 시험 방법을, 중요하지 않습니다 - 중요한 것은 단위 테스트의 존재입니다)
• 테스트되지 않은 코드와 테스트 된 코드 의 버그를 해결하는 데 소요 된 시간

경고해야 할 한 가지 사항 (이 마이그레이션은 명백하지만 주목할 가치가 있음) : 결과 바이어스 -테스트에서 버그를 발견하는 유일한 방법이 해당 버그에 대한 테스트를 작성하는 방법을 선택하지 않았는지 확인하십시오. 일반적으로 아무도 버그가 발생한다는 것을 아무도 모르지만 "X를 테스트했다면이 버그는 사소한 것" 이라고 말하고 싶은 유혹 이 있습니다 . 전쟁이 끝난 후 승리를 거둘 수있는 전술을 찾기가 쉽습니다.

이러한 예의 결과는 간단한 질문이어야합니다. 기능 Y를 개발하는 데 x 시간을 소비 할 수 있다면 왜 2 배로 해야합니까?

먼저 테스트를 작성하지 않는 이유를 알아야합니다.

긴밀한 개발 일정이 종종 이유이지만, 그렇지 않다고 말합니다.

다음 이유는 기존의 테스트되지 않은 코드 기반이 크면 테스트를 작성하는 것이 압도적 인 것처럼 보일 수 있습니다 (세탁과 같은 흥미 진진한 작업). 따라서 인간의 본성은 그것이 직면하기에는 너무 많다고 생각하는 것이므로 생략하겠습니다.

또 다른 이유는 시험이 좋은 생각이라고 생각하지만 시험을 작성한 곳에서 일한 적이없는 경우 특히 시험을 시작하는 방법에 대해 확신 할 수 없기 때문입니다.

또 다른 강력한 가능성은 그들이 아이디어에 립 서비스를 제공하더라도 더 많은 작업에 대한 가치를 실제로 보지 않기 때문입니다.

그래서 다른 이유를 어떻게 처리합니까?

이유는 간단합니다. 개발 시간을 절약하는 방법에 대한 예를 보여주십시오.

두 번째 이유-1 년에 몇 번의 테스트를했는지와 코드베이스의 몇 퍼센트를 다루는 지 보여줍니다. 내년이 시점에 그들이 더 많은 테스트를 할 수 있는지 보여주기 위해 수학을하십시오. 그들이 매일 조금씩 발전해 나가는 것을 본다면, 전체 아이디어가 그렇게 압도적이지는 않습니다. 시스템에서 데이터를 꺼낼 수있는 경우 테스트되지 않은 코드 부분에서 반복되는 버그 수와 단위 테스트를 통해 코드에 반복되는 버그 수를 표시하십시오.

이유 3은 단지 보여주는 것이 아니라 훈련입니다. 훈련 수업에서 시험을 작성하도록하십시오.

이유 4, 이것이 문제의 핵심입니다. 먼저 여러 번 반환 된 버그 중 하나 인 고통 지점을 선택하십시오. 그것이 들어 오면,이 항목에 대해 단위 테스트를 받았다면 나쁜 페니처럼 계속 돌아 오지 않을 것이라고 경영진에게 제안 할 때입니다.

이유 4를 해결하는 또 다른 방법은 관리가 프로세스의 일부로 만들고 테스트가 코드 검토를 통과하지 않는 한 코드가 코드 검토를 통과하지 못하도록하는 것입니다. 이러한 어려움 중 하나 직후 또는 바람직하게는 며칠 동안 여러 번을 한 직후에 정책을 작성하여 접근하는 것이 가장 좋습니다.

우리 모두는 개발자로서 자체 관리 (LOL)를해야한다고 생각하지만, 야심 찬 사람들은 관리가 강조해야 할 사항에 관심을 기울여야하며 실제로 자체 관리를 수행하는 전문가는 이미 테스트를 작성하고 있습니다. 그들이 제품을 향상 시키거나 전문가에게 승진하거나 해고되지 않도록 인상을주는 방법에 대해 걱정하지 않고 전문적인 태도를 취하거나 모범 사례를 수행하지 않는다면, 이것이 귀하에게 적합한 지 고려할 수 있습니다. 경영진이 모범 사례에 관심을 갖지 못하면 오르막 전투를 계속해서 치룰 것이며, 이것이 올바른 회사 문화인지 평가할 수 있습니다. 모든 작업장에 문제가 있지만 도망가는 것이 항상 정답은 아니지만이 장소는 귀하의 전문성 수준에 맞지 않는 것 같습니다.

TDD의 이점을 시연하는 것으로 시작 하겠습니다 . 단위 테스트의 장점을 보여주십시오.

정상적인 인간으로서 개발자는 혜택에 동기를 부여받습니다. 그들은 더 많은 일을 만들어내는 일을하고 싶지 않습니다. 단위 테스트는 적은 작업을 의미합니다 . 친구와 더 나가는 것을 의미합니다. 매일 밤 11 시까 지 코딩을 할 필요가 없기 때문에 더 재미 있어야합니다. 마음의 평화로 휴가를 더 많이 보내는 것을 의미합니다.

TDD의 가장 큰 장점 중 하나는 프로그램을 더 나은 디자인으로 리팩토링 하거나 무언가의 이름을 변경할 수 있다는 것입니다. 디자인이 테스트를 중단하지 않는 한 변경 사항에 대한 100 % 확신을 가질 수 있습니다 아무것도 깨지 않았다.

TDD의 또 다른 좋은 사례는 레거시 코드에 대한 단위 테스트를 만드는 것 입니다. 이것은 악을 리팩토링하는 가장 좋은 방법 중 하나입니다. 장기적으로, 이것은 코드베이스에 대한 지식을 향상시키고, 그 강점과 결함을 이해하고, 코드에서 하드 코딩 된 비즈니스 로직을 발견하고, 품질을 향상시키기위한 좋은 출발점을 제공합니다.

추가 자료를위한 좋은 참고 자료 :

• 단위 테스트를 작성해야하는 이유
• 동기 부여 가시성 및 단위 테스트
• Roy Osherove에 따르면 단위 테스트 기술

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

필자는 얼마 전에 Jeff Atwood 기사에서 해당 링크를 책갈피에 추가 한 것 같습니다 [edit : yep, here is here] . 오래되었지만 관련성이 있습니다. 의심 할 여지없이 다른 답변에 설명되어있는 이러한 이점과 기타 이점으로 인해 프로그래머는 스스로 동기 를 부여 할 수 있어야 합니다 ! 보다 효율적으로 작업 할 수있어 작업이 조금 더 쉬워집니다. 누가 그것을 원하지 않습니까?

두 번째 질문과 관련 하여, 코드 품질 표준에 대한 귀하의 소유권과 자부심은 계속해서 따라야합니다 . 그러한 표준을 갖추어 달성하고자하는 목표와 그 이점을 누리십시오. 내 개인 코드 표준도 실망 스러울 수 있지만 항상 구현하여 세계 / 회사 / 팀에게 호의를 베푸는 것처럼 느낍니다. 그래서 나는 당신이 너무 많은 일을하려고한다고 생각하지 않습니다. 결과는 장소마다 다를 수 있지만 최소한 노력하고 있습니다.

이것은 예를 들어 큰 납 처럼 보인다 .

당신이 싸우고있는 인간 본성의 두 가지 고유 한 측면이 있습니다 :

• 창조적 인 사람들은 프로세스를 좋아하지 않습니다.
• 대부분의 사람들은 품질에 대한 외부 부정적인 판단을 좋아하지 않습니다.

강의, 경영진 선언 또는 논리로이 문제를 해결하기가 매우 어렵습니다. 당신은 인간 본성의 다른 측면을 이용하여 승리해야합니다.

• 사람들은 최고의 직원의 행동을 모방

최고의 직원이 TDD를 사용하고 작동하면 프로세스가 확장됩니다. 그렇지 않으면 그렇지 않습니다. 누군가를 설득해야하는 경우, 1 ~ 2 명의 직원이 최고입니다.

그들에게 묻다.

당신은 사람들에게 이야기를 들었고 더 많은 테스트를 작성해야한다는 데 동의합니다. 왜 그렇지 않습니까?

단순한 동기 부여의 문제가 아닐 수도 있습니다 (종종 그렇지는 않습니다). 그들은 잊어 버릴 수 있습니다. 그들은 시간 압력을 받고 있다고 느낄 수 있습니다. 그들은 좋은 시험을 작성하는 방법을 모른다. 그들은 당신이 너무 좋다고 생각할 수도 있습니다. 근본 원인을 알면 문제를 더 잘 해결하는 데 도움이됩니다.

단위 테스트는 판매 자체가 될 것이라고 생각할 것입니다. 회사의 운영 방식을 모르지만 프로덕션 롤아웃 중에 문제가 발생하면 수정 될 때까지 문제를 해결합니다. 일요일 오전 2시에 발생하는지는 중요하지 않습니다. 이것은 우리에게는 매우 드물지만, 그렇게 할 때 짜증납니다.

한밤중에 몇 번이나 일어나서 쉽게 자동화 테스트를 발견 할 수 있었던 몇 가지 주요 문제를 해결하도록 요청하는 것부터 시작하겠습니다. 그것은 자동화 된 테스트가 모든 것을 고칠 것이라고 말하지는 않지만 그것을 줄이는 데 도움이 될 것입니다.

두 번째로 큰 판매자는 품질 관리주기입니다. 우리 회사에서 TDD를 시작하기 전에 매주 테스트를 위해 새로운 릴리스를 QA로 푸시했습니다. 그들은 그 릴리스에서 버그 더미를 만들 것입니다. 우리는 그 버그를 수정하고 다른 릴리스를 푸시합니다. 끝날 때까지 반복하십시오. 우리가 TDD를 수행 한 첫 번째 프로젝트는 몇 주 후에 QA에 푸시 할 필요가 없었습니다. 그리고 발견 된 버그의 수는 매우 적습니다. 비슷한 프로젝트에 비해 10 %. 어쨌든 팀에 대한 통계를 컴파일해야합니까?

다른 큰 판매 포인트는 코드가 TDD를 받아 들인 후에 어떻게 보 였는지, 테스트하기 쉽도록했기 때문에 읽기가 더 쉬웠습니다. 단위 테스트 용으로 작성된 코드와 작성되지 않은 코드 간의 비교를 보여줍니다.

마지막으로, 자신있게 코드를 리팩터링 할 수있는 방법을 보여주십시오.

필기 시험이 마음에 들지 않을 때는 염두에 두어야합니다. :)

HLGEM의 답변 , 특히이 섹션 을 확장하고 싶습니다 .

다음 이유는 기존의 테스트되지 않은 코드 기반이 크면 테스트를 작성하는 것이 압도적 인 것처럼 보일 수 있습니다 (세탁과 같은 흥미 진진한 작업). 따라서 인간의 본성은 그것이 직면하기에는 너무 많다고 생각하는 것이므로 생략하겠습니다.

내가 쓰는 코드 것으로 나타났습니다 쓰기 테스트의 목적으로는 내가 쓰기 테스트의 의도없이 쓰기 코드보다 훨씬 더 나은 코드입니다; 나 자신에게 묻기이 기능을 어떻게 테스트합니까? 각각의 모든 기능을보다 효과적으로 설계합니다. (전역 또는 반 전역 데이터에 대한 의존도는 낮고, 계산과 분리 된 IO, 함수는 한 가지 작업 만 수행하고, 일관된 오류 처리 등을 수행합니다.)

테스트를 염두에두고 작성되지 않은 이전 코드 에 대한 테스트를 시도 하는 것은 너무 어려울 수 있습니다.

몇 가지 기술을 사용했습니다.

a) 자동화 된 빌드를 설정하십시오. 누군가가 당신이 테스트 한 것을 깨 뜨렸을 때, 테스트에서 어떻게 탐지했는지와 버그가 얼마나 나쁜지를 보여줍니다.

b) 테스트를 통해 복잡한 프로젝트를 수행하십시오 (구동). 해당 프로젝트에 몇 개의 버그가 있는지 보여줍니다. 완벽하게 작동하기 시작한 복잡한 서버 상호 작용 프로젝트가 하나 있습니다. QA에 실패하지 않았으며 모든 통합 테스트는 100 % 순조롭게 진행되었습니다. 이 시스템은 매우 안정적인 것으로 알려졌으며 전반적인 관리에 만족했습니다. 이러한 상황에서 수행하는 작업은 단위 테스트가 어떻게이를 가능하게했는지에 관한 것입니다.

c) 한 번에 한 사람을 잡아 당깁니다. 당신의 말을 듣는 사람. 버그를 극복하고 테스트에서 깊고 어려운 문제가 어떻게 노출되는지 보여줍니다. 도움이됩니다. 결코 쉬운 일이 아닙니다. 그러나 일단 팬이 생기면 그는 도와 줄 것입니다. 도미노 효과입니다.

과정에서 단위 테스트를 굽습니다. 생산에서 버그가 단위 테스트에서 포착하기에 너무 명백한 경우,이 사람은 책임을집니다. 각 시험을 작성하도록 사람들을 지정하십시오. 무작위로 사례를 선택하고 매주 몇 건의 사례를 집행하는 것을 지켜보십시오. 단위 테스트를 통해 사람들은 요구 사항에 대해 묻고 결국 요구 사항을 개발에 연결하고 필요하고 작동하는 소프트웨어를 희망적으로 개발합니다. :)