TDD로 볼을 굴려 라

저는 다른 팀과 협력하여 15 년 이상 사용 된 응용 프로그램을 유지 관리하고 개선하는 개발자 팀의 일원입니다. 처음 만들어 졌을 때 TDD는 들어 본 적이 없습니다.

응용 프로그램은 상당히 안정적이며 쇼 중지 버그가 거의 발생하지 않지만 일주일에 한두 개의 버그가 발생하여 서비스 품질이 크게 저하됩니다. 이러한 버그는 손가락을 가리켜 서 찾아서 수정하는 데 시간이 오래 걸리며 인터페이스 테스트 만 수행합니다. 버그를 수정하기 전에 버그를 찾는 데 많은 시간이 낭비되므로 저와 다른 개발자는 테스트 주도 개발을 제안 할 계획입니다. 새로운 점검이 곧 제공 될 예정이며, 새로운 모듈에서 거의 완전한 단위 테스트를 수행하고자합니다. 또한 기존 코드를 수정해야하는 코드 단위 (예 : 버그 수정 또는 기능 구현)에 대해 테스트 단위를 구축 할 것을 제안합니다. )이지만 문제를 일으키지 않은 코드에 대한 테스트 사례를 개발하는 데 시간을 허비하지 마십시오.

나에게 이것은 합리적인 것 같습니다. 이번 달에 수정하는 데 2 ​​주 이상 걸렸지 만, 유닛 테스트가 완료된 경우 배포 전에 확인 될 수있는 버그가있었습니다. 그러나 우리 관리자에게는 더 많은 돈을 쓰는 것처럼 보입니다.

고객에게 단위 테스트 및 테스트 중심 개발에 돈을 쓰고 싶다고 어떻게 확신 시키나요? 단위 테스트의 ROI를 보여주는 연구가 있습니까?

본격적인 TDD를 레거시 코드에 직접 통합하는 유지 관리 프로젝트는 매우 어려운 판매입니다. 내가 일을 잘 본 접근법은 이것입니다. 들어오는 각 버그에 대해 버그를 보여주는 자동화 된 비 단위 테스트를 작성하십시오. "비 단위"는 시스템의 많은 부분을 만지고 데이터베이스와 파일 시스템에 충돌 할 수있는 것을 의미합니다. 그러나 "자동화 된"이란 인간과의 상호 작용없이 실행되는 것을 의미합니다. 이것은 어떤 경우에도 회귀 모음에서 원하는 종류의 테스트입니다. 코드를 작성하면 많은 일을 수행 할 수 있습니다. 매우 조잡한 수준 일지라도 코드를 테스트 할 수있게하고 버그와 관련이있을 수있는 코드의 별자리에 노출되어 교육 및 정보를 제공합니다. 매우 구체적으로 관련된 자료.

그러나 그것은 끝이 아닙니다. 이 테스트가 실행되고 빨간색으로 실행되면 (코드의 오류를 나타내는) 시간이 걸리면 무엇이 잘못되었는지 파악해야합니다 (어쨌든이 작업을 수행해야 함). 그러나 아직 수정하지 마십시오. 문제가 있다고 생각하는 것을 분리 한 후 단위를 작성하십시오그 문제를 보여주는 테스트. 이제 작업 할 수있는 것이 있습니다 (그리고 우연히 테스트 가능성을 높이기 위해 더 많은 것을 리팩토링해야 할 수도 있습니다). 버그를 수정하십시오. 단위 테스트 패스를 확인하십시오. 어쩌면 약간의 경우로 육체를 만들 수도 있습니다. 단 2 주만에 비용을 지불 한 단 하나의 유닛을 견고하고 깨끗하며 잘 테스트하십시오. 이제 회귀 테스트를 실행하고 통과했는지 확인하십시오 (물론 그렇지 않은 경우 더 많은 연구와 단위 수준의 작업을 수행해야합니다-반복 될 때까지 반복하십시오). 모두 확인하십시오. 무엇을 얻었습니까? 이전에 실패한 코드에 대한 회귀 테스트 이전에 실패한 코드에 대한 단위 테스트. 실패한 작업 코드. 더 나은 디자인 코드. 이제는 코드보다 테스트가 가능하기 때문입니다. 코드베이스에 대한 자신감 향상

"순수한"TDD가 아닙니다. 그러나 결과를 신속하게 보여주고 시간이 지남에 따라 코드의 품질을 향상시킵니다. 결과는 경영진을 인수하는 데 도움이됩니다.

우리 회사에서는 JoelOnSoftware의 "단순한"방법으로 방금 콘솔 응용 프로그램을 해킹 할 때마다 단위 테스트를 작성하기 시작했습니다. 보다 안정적인 릴리스로 훨씬 빨리 작업을 시작했으며 그 사실을 알게되었습니다. 내가하고있는 일을 물었을 때, 나는 오래된 코드를 수정하거나 새로운 코드를 작성할 때마다 TDD를 사용하고 단위 테스트를 작성하기 시작했다고 설명했습니다. 동료 개발자들은 궁금해하기 시작했고 통합 단위 테스트 자체를 사용하기 시작했습니다. 레거시 코드 작업을위한 테스트 작성에 대한 좋은 주장은 없지만, 자동화 된 테스트 작성이 콘솔 핵 스파게티를 작성하는 것보다 더 빠르고 편리 하다고 생각할 수 있다면, 똑똑한 개발자가 따라갈 것입니다.더 높은 품질의 소프트웨어를 제공하는 다른 이점들도있을 것입니다. 그러나 개발자의 사인을 얻는 열쇠는 그들의 삶이 더 쉬워진다는 것을 보여주는 것입니다. 비즈니스에 서명하는 한, 소프트웨어가 향상되고 이전보다 배송 시간이 단축 될 수 있다는 사실은 소프트웨어를 설득하기에 충분해야합니다.

우선, 고객의 돈에 가치를 더하는 품질 가치에 대한 태도와 성실함을 높이 평가해야합니다. 관리자와 고객을 설득 할 수있는 방법에 대한 나의 생각은 다음과 같습니다.

• 지난 6 개월 동안 수정 한 버그의 통계와 버그를 수정하는 데 걸린 최소, 평균 및 최대 시간을 수집하십시오.
• 수정했거나 컨텍스트가있는 모든 버그에 대해 해당 영역을 다루는 단위 테스트를 작성하십시오.
• 작업중인 버그와 작업 할 버그에 대해서는 변경하기 전에 해당 영역에 대해 단위 테스트를 작성하십시오. 그런 다음 원인을 파악하고 수정하는 코드를 작성하십시오. 기존 테스트 사례를 위반하는지 확인하십시오. 그렇다면, 동료들이 단위 테스트의 중요성을 이해하고 설명하도록하십시오.
• 모든 개발자가 단위 테스트의 중요성을 이해 한 후에는 며칠 / 주 동안 수행 한 작업을 계속 수행하도록 요청하십시오.
• 시간이 지남에 따라 팀 생산성은 관리자와 고객 모두 생산성 향상과 코드 품질에 놀랄 정도로 향상되어야합니다. 시간이 조금 걸리지 만 시도해 볼 가치가 있습니다.

다른 방법이 있으며 주변에서 발생하는 민첩한 회의에 관리자와 함께 참여하는 것이 좋습니다. 반드시 참석할 가치가 있습니다.

아무것도 효과가 없다고 생각되면 계속 움직여 라. 솔직히 이것은 내가 한 일입니다. 모든 것이 실패했을 때 나는 계속 움직였다.)

코드를 작성한 후 Unit Test가 실제로 TDD가 아닌 것이 무엇인지 알고 있지만 이것이 항상 첫 번째 단계가 될 수 있습니다. 여기에 아주 잘 맞습니다.

행운과 성공을 기원합니다!