단위 테스트는 훌륭하게 들리지만 중요한 가치가있는 다른 사람들을 설득 할 수 없다면 실제로 그것을 배우는 데 시간을 투자 해야할지 확실하지 않습니다. 나는 다른 프로그래머들, 더 중요하게는 경영진의 빈 카운터 (counter-counters)에게 테스트 프레임 워크를 배우고, 테스트를 작성하고, 업데이트를 유지하는 등의 시간이 추가로 소요될 것이라고 확신해야한다.
어떤 증거가 있습니까? 실제로 두 사람이 서로 다른 두 팀으로 동일한 소프트웨어를 개발 했습니까? 하나는 단위 테스트를 사용하고 다른 하나는 사용하지 않았습니까? 나는 그것을 의심한다. 난 그냥 "인터넷에서 찾아 봐, 모두가 그것에 대해 이야기하고 있기 때문에 그것이 옳은 일이어야한다"고 정당화해야합니까?
평신도들에게 단위 테스트가 노력할만한 가치가 있음을 확신시킬 수있는 확실한 증거는 어디에 있습니까?
답변:
예. 이것은이다 링크 NCST에서 보비 조지와 로리 윌리엄스의 연구에와 다른 Nagappan 등으로. 나는 더 많은 것이 확신합니다. 테스트에 관한 Dr. Williams 간행물 은이를 찾는 좋은 출발점이 될 수 있습니다.
[편집] 위의 두 논문은 구체적으로 TDD를 참조하며 TDD를 채택한 후 초기 개발 시간이 15-35 % 증가하지만 시험판 결함은 40-90 % 감소합니다. 전체 텍스트 버전을 구할 수없는 경우 Google Scholar 를 사용하여 공개적으로 사용 가능한 버전을 찾을 수 있는지 확인하시기 바랍니다.
"나는 다른 프로그래머들, 더 중요한 것은 관리에있는 빈 카운터를 대화해야한다. 여분의 시간은 테스팅 프레임 워크를 배우고, 테스트를 작성하고, 업데이트를 유지하는 등의 시간이 소요될 것이다. "
왜?
조용하고 신중하게 그렇게하지 않는 이유는 무엇입니까? 한 번에 모두 할 필요는 없습니다. 작은 작은 조각으로 이것을 할 수 있습니다.
프레임 워크 학습에는 시간이 거의 걸리지 않습니다.
단 하나의 테스트를 작성하는 데는 시간이 거의 걸리지 않습니다.
단위 테스트 없이는 소프트웨어에 대한 확신이 있습니다. 하나의 단위 테스트로도 자신감이 있으며 하나 이상의 테스트가 통과했음을 증명할 수 있습니다.
그게 다야. 아무도 당신이하고있는 것을 알 필요가 없습니다. 그냥 해.
나는 이것에 대해 다른 접근법을 취한다.
코드가 올바른지 어떤 보증을합니까? 아니면 팀의 누군가가 func1 ()을 변경할 때 가정 X를 위반하지 않습니까? '정직'을 유지하는 단위 테스트가 없으면 많은 확신이 없습니다.
테스트를 최신 상태로 유지한다는 개념은 흥미 롭습니다. 테스트 자체는 종종 변경 될 필요가 없습니다. 내가 생산 코드에 비해 테스트 코드를 3 배있어, 그리고 테스트 코드가 변경되었습니다 아주 작은. 그러나 밤에 잘자는 것은 물론 고객에게 시스템을 손상시키지 않고 Y 기능을 구현할 수 있다는 확신을 가지고 있습니다.
아마도 학계에서는 증거가있을 수 있지만, 상업 테스트를 한 사람이라면 누구나 그런 시험에 대한 비용을 지불 한 적이 없습니다. 나는 테스트 프레임 워크에 익숙해 질 및 쓰기 시험은 내가 만든, 나를 위해 잘 작동하고있다, 그러나, 당신에게 약간의 시간이 걸렸습니다 수 있습니다 정말 훨씬 더, 내 요구 사항과 디자인에 대해 생각 팀에 작업 할 때 내가 이제까지했던 것보다 그 테스트를 작성하지 않았습니다.
1) 코드에 대한 확신이 있고 2) 그렇지 않은 경우보다 더 일찍 문제를 발견합니다. 당신은 품질 보증 사람이 봐, 당신은 XYZ () 함수를 경계 검사는? 않았다 귀찮게하지 않았다 "말을하지 않아도 그는 때문 버그를 찾을 수 없습니다 당신 이 한 달 전에 발견했다. 그건 좋다 그를 위해, 당신을 위해, 회사를 위해 그리고 고객을 위해.
분명히 이것은 일화이지만, 나를 위해 놀라운 일을했습니다. 스프레드 시트를 제공 할 수 있는지 확실하지 않지만 고객은 행복하며 이것이 최종 목표입니다.
단위 테스트 없이도 크 래피 소프트웨어를 작성할 수 있다는 확실한 증거가 있습니다. 단위 테스트를 통해 엉터리 소프트웨어에 대한 증거조차 있다고 생각합니다. 그러나 이것은 요점이 아닙니다.
단위 테스팅 또는 TDD (Test Driven Development)는 테스트 테크닉이 아닌 디자인 테크닉입니다. 테스트로 작성된 코드는 그렇지 않은 코드와 완전히 다르게 보입니다.
이것이 귀하의 질문이 아니지만, 실제로 길을 가고 잘못 질문받을 수있는 질문에 답하고 다른 보고서에서 도전 할 수있는 증거를 가져 오는 가장 쉬운 방법인지 궁금합니다. 사건에 대한 확실한 증거를 찾더라도 다른 사람이 이에 대한 확실한 증거를 찾을 수 있습니다.
기술 담당자의 작업 방식을 결정하는 것이 빈 카운터의 사업입니까? 그들은 더 비싼 도구가 필요하지 않다고 생각하기 때문에 모든 경우에 가장 저렴한 도구를 제공합니까?
이 주장은 신뢰 (애자일 팀의 기본 가치 중 하나)를 기반으로이기거나 승리 한 당사자의 역할을 기반으로 상실됩니다. TDD 지지자들이 역할의 힘으로이기더라도 나는 그것을 잃어버린 것으로 간주합니다.
단위 테스트에 대한 증거에 관심이 있다면 여기에 잘 연구되고 고려 된 기사가 있습니다.
엄격하게 단위 테스트보다 TDD에 대한 자세한 내용은 Nagappan, E. Michael Maximilien, Thirumalesh Bhat 및 Laurie Williams 의 네 가지 산업 팀 논문 의 결과 및 경험과 같은 테스트 중심 개발을 통한 품질 향상 실현에 대한 링크 입니다. Microsoft Empirical Software Engineering and Measurement (ESM) 그룹이 발간 한 논문은 이미 여기에 언급되어 있습니다.
팀은 TDD 팀이 비 TDD 팀보다 60 % ~ 90 % 더 나은 (결함 밀도 측면에서) 코드를 생성한다는 사실을 발견했습니다. 그러나 TDD 팀은 프로젝트를 완료하는 데 15 ~ 35 % 더 오래 걸렸습니다.
여기에 회사를 바꾸는 사람에 대한 대단하고 재미있는 글이 있습니다. TDD에만 국한되지 않습니다. http://jamesshore.com/Change-Diary/ 그는 "콩 카운터"를 꽤 오랫동안 설득하지 않았고 대신 "게릴라 전술"을 수행했습니다.
이 답변에 더 많은 정보를 추가하기 위해 학술 및 산업 배경에 대한 생산성 및 품질 영향을 파악하는 데 도움이되는 두 가지 메타 분석 리소스가 있습니다.
모든 연구자들은 TDD가 더 나은 작업 초점과 테스트 범위를 장려한다는 데 동의하는 것 같습니다. 테스트가 더 많다고해서 반드시 소프트웨어 품질이 더 좋아지는 것은 아니지만 테스트 설계에 대한 프로그래머의 관심이 높아지는 것은 고무적입니다. 테스트를 통해 잠재적 인 대량의 행동을 샘플링하는 것으로 볼 때 더 많은 테스트는 더 철저한 샘플을 의미합니다. 각 테스트가 다른 테스트에서 찾을 수없는 중요한 문제를 발견 할 수있는 범위 내에서, 특히 저렴하게 실행할 수있는 경우 테스트가 유용합니다.
표 1. 테스트 주도 개발에 대한 선택된 경험적 연구 요약 : 업계 참가자 *
표 2. TDD : 학술 참가자 *의 선택된 경험적 연구 요약
요약:
이 논문은 TDD (Test-Driven Development)가 외부 코드 품질 및 생산성에 미치는 영향을 조사하는 27 개 연구의 체계적인 메타 분석을 제공합니다.
결과는 일반적으로 TDD가 품질에 작은 긍정적 영향을 미치지 만 생산성에 별다른 영향을 미치지 않음을 나타냅니다. 그러나 하위 그룹 분석은 학업 연구에 비해 산업 연구에서 품질 개선 및 생산성 저하가 훨씬 더 컸음을 발견했습니다. TDD와 통제 그룹 프로세스 사이의 시험 노력의 차이가 중요한 연구에서 생산성이 크게 떨어졌습니다. 시험 노력의 차이가 상당 할 때 학술 연구에서도 품질이 크게 향상되었습니다. 그러나 데이터 부족으로 인해 산업 연구에 관한 결론을 도출 할 수 없었습니다.
마지막으로, 중재자 변수로서 개발자 경험과 작업 크기의 영향을 조사하고, 작업 크기와 품질 향상의 크기간에 통계적으로 유의 한 양의 상관 관계가 발견되었습니다.
글쎄, 당신은 단위 테스트를 사용해야하는 대기업이 있지만 소규모 회사라면 왜 대기업을 모방합니까?
몇 년 전에 단위 테스트를 시작했을 때 저에게 (오늘 우리는 주로 행동을 사용합니다 모델을 합니다) 하나의 응용 프로그램에서 모든 경로를 제어 할 수 없기 때문이었습니다.
나는 첫 번째 프로그래밍과 REPL을 구사하는 데 익숙했기 때문에 단위 테스트 (모든 기능에 대해 하나의 테스트)를 받았을 때 REPL을 컴파일하는 언어로 다시 가져 오는 것과 같았습니다. 그것은 내가 작성한 모든 코드 줄에 재미를 가져 왔습니다. 나는 신을 느꼈다. 나는 그것을 좋아. 더 나은 코드를 더 빨리 작성하기 시작했음을 알리는 보고서가 필요하지 않았습니다. 상사는보고를 할 필요가 없었습니다. 상사는 비생산적인 코드를 작성하는 매우 이상한 일로 인해 "일반"버그 수가 거의 없음에서 거의 없음으로 떨어질 것이라는보고를 할 필요가 없었습니다.
다른 포스터가 이미 작성한 것처럼 TDD를 사용하여 테스트 (확인)하지 않습니다. 스펙, 유닛 (객체, 모듈, 함수, 클래스, 서버, 클러스터)의 작동 방식을 캡처하기 위해 작성합니다.
많은 회사에서 소프트웨어 개발의 다른 모델로 전환 한 것에 대한 많은 실패와 성공 사례가 있습니다.
새로운 것을 쓸 때마다 방금 사용하기 시작했습니다. 영어로 번역하기가 다소 어려워지는 오래된 말이 있습니다.
그렇게하는 것을 눈치 채지 못할 정도로 간단한 것으로 시작하십시오. 마라톤 훈련을 할 때는 9 미터를 걸어 1 미터를 달리면서 시작하십시오.
단위 / 통합 테스트에서 발견 된 버그를 수정하면 실제 시스템에서 수정하는 것보다 비용이 몇 배나 적게 든다는 통계가 있습니다 (수천 개의 실제 프로젝트 모니터링에 기반 함).
편집 : 예를 들어 " Code Complete "라는 책 은 그러한 연구에 대해보고합니다 (20.3 절. "품질 기법의 상대적 효과 성"). 그러나 컨설팅 분야에서도이를 입증하는 민간 연구도 있습니다.
단위 테스트에서 나에게 팔린 경험을 바탕으로 한 가지 데이터 포인트가 있습니다.
많은 달 전에 저는 큰 VB6 프로젝트에서 일하는 신입생이었으며, 많은 저장 프로 시저 코드를 작성할 기회가있었습니다. 하위 시스템 중 전체 코드베이스의 약 1/4을 구성하여 50K 정도에서 약 13,000 LOC를 작성했습니다.
스토어드 프로 시저에 대한 단위 테스트 세트를 작성했지만 Rational Robot과 같은 도구가 없으면 단위 테스트 VB6 UI 코드를 실제로 실행할 수 없습니다. 적어도 그때는 아니 었습니다.
QA의 통계는 전체 서브 시스템에서 약 40 개 또는 50 개의 결함이 발생했으며 그 중 2 개 는 저장 프로 시저에서 시작된 것입니다. 그건 하나의 코드 결함 6,500 당 라인을 전체 당 1,000 개 ~ 1,200 개당 1 . 또한 VB6 코드의 약 2/3는 오류 처리 및 로깅을위한 상용구 코드였으며 모든 절차에서 동일합니다.
손으로 너무 많이 바르지 않으면 단위 테스트에 결함 비율이 적어도 몇 배나 향상 될 수 있습니다.
