단위 및 통합 테스트 : 반사가되는 방법

팀의 모든 프로그래머는 단위 테스트 및 통합 테스트에 익숙합니다. 우리는 모두 함께 일했습니다. 우리는 모든 서면 시험을 가지고 있습니다. 우리 중 일부는 자신의 코드에 대한 향상된 신뢰감을 느꼈습니다.

그러나 어떤 이유로 든 단위 / 통합 테스트를 작성하는 것은 팀 구성원 중 누구에게도 반영되지 않았습니다. 실제 코드와 동시에 단위 테스트를 작성하지 않을 때 실제로 기분이 좋지 않습니다. 결과적으로, 우리의 코드베이스는 대부분 단위 테스트로 밝혀졌으며 프로젝트는 테스트되지 않은 채로 생산됩니다.

물론 문제는 일단 프로젝트가 생산되고 있고 이미 잘 작동하고 있다면 단위 / 통합 테스트를 추가하는 데 시간과 예산을 확보하는 것이 사실상 불가능하다는 것입니다.

팀원과 본인은 이미 단위 테스트의 가치에 익숙 하지만 ( 1 , 2 ) 단위 테스트를 자연스러운 워크 플로우로 가져 오는 데 도움이되지 않는 것 같습니다. 필자의 경험에 따르면 단위 테스트 및 / 또는 대상 범위를 강제로 설정하면 품질 테스트가 열악 해져서 이러한 테스트를 생성하는 자체 생성 동기가 없기 때문에 팀 구성원의 속도가 느려집니다. 또한 압력이 완화되는 즉시 단위 테스트는 더 이상 작성되지 않습니다.

내 질문은 다음과 같습니다. 팀 내에서 역동적 / 운동량을 구축하는 데 도움이되는 실험 방법이 있습니까? 사람들이 자연스럽게 테스트를 만들고 유지하기를 원합니다.

실제 코드와 동시에 단위 테스트를 작성하지 않을 때 실제로 기분이 좋지 않습니다.

이것이 당신이 다루어야 할 요점입니다. 스프린트 (또는 사용하는 시간 단위) 동안 테스트를 작성하지 않으면 하드 코딩 값만큼 코드 냄새가 나도록 팀의 문화를 바꿔야합니다. 그것의 대부분은 동료 압력과 관련이 있습니다. 아무도 실제로 표준 이하로보고 싶어하지 않습니다.

직접 테스트하십시오. 당신이 그들을하지 않을 때 눈에 띄게 자신을 비난. "좋은"프로그래머가 유닛 테스트를 작성한다면 그 버그를 잡은 곳을 지적하십시오. 누구도 나쁘기를 원하지 않습니다. 이 바람직하지 않은 행동이 나쁘고 사람들이 따르게하십시오.

팀 전체가 실제로 같은 것을 원하게 하는 것은 매우 어려울 수 있습니다. 사람들이 뿌리 깊은 행동을 바꾸도록 장려하기 위해 무언가의 가치를 보는 것만으로는 충분하지 않은 경우가 종종 있습니다. 변화를 소중히 여기고 구체적으로 원하는 사람들조차도 무의식적으로 변화에 대한 책임을 질 수 있습니다.

문제는 실제로 개인 동기 중 하나이며 팀 동기 부여가 아닙니다. 당신이 마지막으로 이해했다고 느낀 결과, 또는 새로운 툴이나 일반 프로그래머가 모든 것을 던져 프로세스를 완전히 바꾸게하는 다른 주관적인 일 때문에 분명한 순간이 당신에게 도달 할 때가 온다. 당신이 할 일을 제외하고 당신이해야 할 일은 당신이나 팀이 어떤 것이 각 팀원에게 명확성을 유발할 수 있는지 알아내는 방법이 있는지 확인하는 것 입니다.

개인적으로 그것은 DotNet에서 BDD 에 대한 StoryQ 프레임 워크를 발견하는 것이 었 습니다. 무시하기가 너무 쉬웠으며 테스트 우선 대 테스트 동시 "배리어"를 완전히 넘어 갔습니다 . 나중에 Visual Studio 용 NCrunch 를 찾았을 때 선택 사항을 다시 확인했습니다 . 때로는 전투의 절반이 아이디어를 파는 것이 아니라 습관에 급진적 인 변화를 가져 오는 데 필요한 노력을 낮추는 것입니다. 심지어 시간과 노력이 조금 걸릴 수도 있습니다. 그러나 이러한 동일한 개인 트리거는 동시에 테스트 코드의 많은 부분을 동시에 또는 구현 코드 후에 작성하는 동료의 접근 방식을 흔들기에는 충분하지 않았습니다.

때로는 변화에 대한 추론이 건전한 경우에도 무언가를 다르게 배우는 데 필요한 노력에 대한 두려움, 불신 또는 불쾌한 견해 때문에 일이 수행되는 방식을 바꾸는 것을 꺼리는 경우도 있습니다. 전체 테스트 플랫폼이 특정 방식으로 작동하도록 툴링 된 경우, 작업 방식을 변경하고 툴링을 변경하는 것을 정당화하기 어려울 수 있습니다 . 특히 오래된 테스트와 새로운 테스트가 수명 기간 동안 계속 공존해야하는 경우 프로젝트-그리고 당신은 확실히 당신이 만든 모든 테스트를 다시 작성하고 싶지 않을 것입니다. 이상한 점은 때때로 사람들이 이것이 새로운 테스트 방법론을 채택하는 유일한 방법이라고 느끼고 그 자체로 사람들이 현명한 변화를 더 잘 받아들이는 것을 어렵게한다는 것입니다.

실제로, 재귀가되는 유일한 방법은 더 이상 자신이 그것을하는 방법에 지나치게 집중할 필요가 없다는 것을 더 이상 눈치 채지 못할 때까지 반복해서 반복하도록하는 것입니다. 때로는 팀에서이 작업을 수행 할 수있는 유일한 방법은 약간 까다로운 정책을 설정하고 페어 프로그래밍 및 코드 검토 및 팀 구성원이 서로를 백업하고 문자 그대로 변경을 강요 하는 데 도움이 될 수있는 정책을 설정하는 것입니다. 행동에. 그러나 이러한 전략이 실제로 성공하기 위해서는 각 팀원마다 필요한 조치를 취하고 프로세스에 참여하고 모든 참여자의 인내심을 가져야한다는 확고하고 정직한 헌신이 필요합니다. .

실제 코드와 동시에 단위 테스트를 작성하지 않을 때 실제로 기분이 좋지 않습니다.

"동시에"의 의미가 무엇인지 모르지만 실제 코드 앞에 작성하는 것은 어떻습니까?

어떤 인간이 코드 후에 단위 테스트를 작성하고 싶지 않은 이유는 심리적 관점에서 쉽게 이해할 수 있습니다. 그 시점에서 코드가 이미 작동하고 있으므로 왜 지구상에서 코드를 테스트해야합니까? 어떤 종류의 게으름은 지루하고, 쓸모없는 것처럼 보이며 필기 시험을 작성하지 않아도 위험하지 않기 때문에 자동으로 발생합니다. 결과적으로 오랜 기간 동안 테스트 후 접근 방식을 유지 한 많은 팀을 알지 못합니다.

내 경험상, 테스트 우선 (TDD 스타일)은 적어도 2 가지의 즉각적이고 가시적이며 엔돌핀 방출 이점이 있기 때문에 빠르게 중독 될 수있는 것입니다.

• 구체적인 실행 가능 요구 사항으로 코드 대면을 디자인하고 리팩토링 할 때 디자인을 더 좋게 개선하는 데 도움이됩니다. 이는 이미 작동하는 것을 다시 확인하는 것보다 훨씬 더 유용하고 만족 스럽습니다.

• TDD 사이클은 즉각적인 성공의 맛을 즐길 수있는 빈번한 "녹색 막대"순간으로 잘립니다. 지속적으로 마음을 만족시키고 다음 기능을 구현할 준비를합니다.

팀 이 테스트를 작성하지 않았을 때 기분이 나쁘게 만들려고 하지 않습니다. 대신, 나는 그들이 하는 것처럼 기분이 좋게 만들려고 노력했다 . TDD가이를 수행하는 한 가지 방법입니다.

먼저 테스트 작성 및 실행이 쉬워야하고, 현재 프로젝트에서 프레임 워크를 설정하고, 향후 프로젝트에 포함하기 위해 해당 설정 절차를 간단하게 만들어야합니다.

이 방법으로 프로그래머는 새로운 기능을 unittest하고 싶을 때 디버그하려고합니다. 테스트를 제대로 실행하기 위해 수십 개의 농구대를 뛰어 넘을 필요가 없습니다.

더 어색한 행동은 습관을 들이지 않을 가능성이 적습니다.

문화 변화를 주도하는 데 어느 정도 성공한 것은 한 주 단위로 "단위 테스트 큐 레이션"세미나를 시작하는 것입니다. 이것의 공식적인 목적은 단위 테스트 스위트를 빠르게 실행하고 최신 상태로 유지하는 데 도움이되지만, 가장 중요한 목적은 사람들에게 부담을 느끼고 질문하고 시험을 연습 할 수있는 저압 방법을 제공하는 것입니다. . 테스트에 독점적으로 한 시간 또는 일주일을 보내 겠다는 사실은 이것이 중요하다는 메시지를 보냅니다.

나는 당신이 이런 식으로 약간의 문화 변화를 겪고 있다고 생각합니다. 사람들은 역경의 첫 징후로 오래된 습관으로 되돌아가는 경향이 있습니다. 이와 같은 회의를 통해 한 번에 문제를 해결할 수는 없지만 문화 변화를 일으키고 실제로 발생하지 않는 장벽을 제거 할 것이라고 생각합니다. 당신이하고있는 것을 아는 것.

모두가 자연스럽게 무언가를하고 싶은 프로그래머 그룹을 갖는 것은 어리석은 일입니다 (특히 큰 그룹에 대해 이야기 할 때).

단위 및 통합 테스트는 표준 입니다. 워크 플로우에 대한 표준을 작성하면 팀의 각 구성원이이를 준수해야합니다. 표준은 QA 전문가의 도움을 받아 더 잘 알고 있어야합니다. 프로그래머는 표준을 존중해야합니다. 당신이 할 수있는 일은 표준을 깨끗하고 이해하기 쉽고 따르게하는 것입니다.

그것은 자신의 코드에 대한 신뢰와 사용을 원치 않으며, 좋은 일을하기 위해 모든 사람이 사용하는 코딩 및 테스트 표준을 필요로하며, 프로그래머는 이것을 이해해야합니다.

처음부터 사람들이 표준을 따르게하면 반사가되어 따르게됩니다. 단위 테스트없이 코드베이스에 코드를 넣을 수 없다는 규칙을 만들면 사람들이 코드를 작성해야한다고 확신 할 수 있습니다. 프로젝트 리포지토리의 경우 훨씬 더 제한적인 규칙이 있습니다. 예를 들어, 회사는 실제로 장치를 코딩하기 전에 (모듈 사양을 만들 때) 단위 테스트를 수행하며 이는 매우 좋은 방법입니다. 프로그래머가 프로젝트 / 코드베이스에 코드를 넣으면 코드가 테스트 모듈을 통해 실행되고 단위 테스트가 통과하지 않으면 다시 작동합니다.

현재 표준과 규칙을 추가하기 어려운 경우 최소한 향후 프로젝트에 추가 할 것을 고려하십시오.