TDD가 품질 및 / 또는 개발 속도를 향상시키는 방법에 대한 사례 연구를 찾고 있습니다.

우리 회사에서 우리가 왜 TDD를해야하는지에 대한 사례를 만들려고합니다. 현재 대부분의 개발자는 프로젝트를 수행하기 위해 가능한 모든 작업을 수행 한 다음 관리자 메트릭을 충족시키기 위해 사실 이후 단위 테스트를 추가합니다. TDD를 수행하고 혜택을 보는 평판 좋은 회사의 사례는 크게 감사하겠습니다.

IBM과 Microsoft의 4 가지 프로젝트에 대한 연구. Emperical Software Engineering 저널에 게시되었습니다 .

경험적 연구에 따르면 테스트 중심 개발로 품질 향상

Empirical Software Engineering 저널에 처음 발표 된 한 논문은 "TDD는 다양한 영역에 적용 할 수있는 것으로 보이며 개발 팀의 생산성을 크게 저하시키지 않으면 서 개발 된 소프트웨어의 결함 밀도를 크게 줄일 수 있습니다." 이 연구는 TDD를 사용하지 않은 유사한 프로젝트와 함께 TDD를 사용하는 Microsoft와 IBM의 4 개 프로젝트를 비교했습니다 ...

이 백서에는 IBM의 사례 연구 1 개와 Microsoft의 사례 연구 3 개가 포함되어 있습니다. 각 사례 연구는 동일한 상위 레벨 관리자하에 동일한 개발 언어 및 기술을 사용하여 동일한 제품을 작업하는 두 팀을 비교합니다.이 중 한 팀만이 테스트 중심 개발 (TDD)을 사용했습니다. 어느 팀도 개발주기 동안 연구에 참여할 것이라는 것을 아무도 알지 못했습니다. IBM 사례 연구는 장치 드라이버 개발을 수행하는 팀을 따랐습니다. Microsoft 사례는 Windows, MSN 및 Visual Studio에서 작업하는 팀을 따랐습니다.

이 백서는 팀에서 사용하는 TDD 사례를 분 단위 워크 플로 및 작업 수준 워크 플로로 설명합니다.

최근의 "Making Software : 무엇이 작동하고 우리가 그것을 믿는 이유"의 사례 연구와 함께 TDD에 관한 장이 있습니다. 그러나 내가 올바르게 기억한다면 연구가 TDD에 대한 실질적인 이점을 발견하지 못했기 때문에 실망 할 것입니다. 어쨌든 사례 연구는 흥미 로웠으며 일반적으로이 책은 최근에 읽은 최고의 소프트웨어 책 중 하나입니다. 페어 프로그래밍, 코드 검토 등과 같은 많은 사례 연구가 포함되어 있습니다.

: 확실히이 체크 아웃 효과가 입증 TDD를! 아니면?

... Phil Haack이 Research가 TDD의 효과를 지원 한다고 발표했을 때 , 나는 링크 된 보고서가 실제로 무엇을 포함 하는지 보는 데 조금 관심 이있었습니다. 필은 초록에서 인용합니다.

우리는 시험을 치르는 학생들이 평균적으로 더 많은 시험을 보았고, 더 많은 시험을 보인 학생들은 더 생산적인 경향이 있음을 발견했습니다. 또한 사용 된 개발 전략에 관계없이 프로그래머 테스트 수에 따라 최소 품질이 선형으로 증가하는 것을 관찰했습니다.

Phil은 보고서의 나머지 부분을 분명히 읽었으며 제목이 제안하는 것처럼 보이는 좋아하는 작품을 제공합니다. 나는 일이 최신의 그리고 최고의 소프트웨어 개발 방법을 지원 볼 때 걱정 것들 중 하나는, 그러나, 대한 강한 경향이 확인 바이어스 전류 이론의 확인을 찾고 카운터 지표를 간과 -.

그래서 호기심이 많은 유형이며 TDD는 언젠가 내가 채택하고 싶은 것이 있는지 계속 지켜보고있는 것이므로 보고서에 들어갔습니다 ...

... 물론, 테스트는 먼저 기능 단위당 더 많은 테스트를 수행합니다. 문제는 이것이 가치가 있는지입니다. 이 연구는 적어도 품질이 의도 한 이득이라면 이것이 사실이 아닐 수도 있음을 나타냅니다. 그러나 코드 줄 수가 생산성에 해당하지 않는다는 사실에 놀라지 않는 것처럼 테스트 수는 품질에 해당하지 않는다는 사실에 놀랄 일이 아닙니다.

저자는 TDD가 그다지 효과적이지 않다는 점에 대해 많은 좋은 점을 가지고 있습니다 (죽음에 걸렸음에도 불구하고 imo)

귀하 와 고객 이 소프트웨어를 수동으로 테스트하는 데 걸린 시간을 확인 하십시오. TDD 스타일의 자동 테스트에 소요 된 시간을 추정하십시오. 차이를 포켓

내 경험상 TDD의 자동 테스트는 보험 을 제공 하고 엄청난 양의 수동 테스트를 제거 하기 때문에 금 입니다.

Andres F가 지적했듯이 TDD가 아니라 자동화 된 테스트를 통해서만 이러한 이점을 얻을 수 있습니다. 그러나 TDD 는 나중에 생각하거나 사용하기 쉬운 대신 자동화 된 테스트를 요구합니다.

테스트에 대해 먼저 생각해야하므로 코드 작성을 시작하기 전에 모듈성, 인터페이스 디자인 등과 같은 품질 관련 문제에 대해 생각해야합니다.

개인적으로, TDD의 가장 큰 장점 중 하나는 테스트 작성이 먼저 코드를 작성하는 대신 코드를 작성하는 동안 실제로 코드가 실제로 수행해야 할 사항의 사양을 유지한다는 것입니다. 코드로.

다음 프로젝트를 위해 제안한 다음 배우십시오. 그것이 당신을 위해 잘 작동하는 것으로 판명되면, 나는 당신이 그것을 계속 사용하기를 바랍니다. 그리고 프로젝트를 수행하는 데 더 오래 걸렸거나 코드 대신 테스트를 작성하는 데 모든 시간을 소비한다면, 당신은 그것을 다음과 같이 버릴 것입니다 : 실패.

실제 솔루션은 중간에 있다고 생각합니다. 테스트를 원하지만 테스트가 프로젝트보다 중요하지는 않습니다.

(개인적으로 나는 TDD가 유행이라고 생각하지만 이론 상으로는 좋지만 실제로는 그렇게 좋지는 않습니다. 통합 테스트가 훨씬 중요하다는 것을 알았습니다.

저는 2 년 동안 TDD를 사용하고 당시 근무했던 곳에서 관리자를 포함하여 모두 사용하는 것을 꺼려했지만 곧 올바른 일이되었습니다.

• 초기 단계에서 버그 발견.
• 실현하지 않고도 더 나은 코드 작성
• 테스트로 인해 코드가 유지 관리가 쉬워졌습니다 (우리는 300-400 줄의 기능을 가지고 있음). 이제 최대 30 개이며 모두 독립적으로 테스트되었습니다.

관리자는 "완료했습니다"라는 한 가지 사항에 모두 관심이 있으므로 알 수 없습니다. 그러나 그들은 소프트웨어가 깨달 지 않고 끊어 질 때 불평합니다. 적용 범위가 넓고 현명한 테스트로 누군가가 기능을 위반했을 때 실제로 볼 수있는 양이 아니라 품질입니다. 불행히도 당신이 혼자라면 어렵다. 나는 같은 문제가 있었다. 예를 들어 기본 클래스 등의 코드를 변경해야 소프트웨어의 일부를 테스트 할 수있다.

예를 들어 리포지토리를 조롱하고 싶었지만 인터페이스가 없었기 때문에 리포지토리를 서비스 계층에 주입해야하므로 상점 전체에 생성자를 추가 / 수정해야합니다. 이것은 큰 문제이지만 결국 나는 시스템의 한 영역을 테스트하는 200 개 이상의 테스트를 받았으며 감동했습니다.

나는 보통 다음을 수행합니다.

• 나는 단위 테스트를 매우 짧게 유지합니다
• 러시아 룰렛은 없습니다.
• 긍정적이고 부정적인 예외 시나리오를 테스트합니다.

사례 연구와 관련하여 두렵습니다. 프로젝트를 구축하고 사례 연구가되어야합니다.

나는 그것이 도움이되기를 바랍니다