단위 테스트 개발과 테스트 미개발 사이의 시간 차이

저는 개발 시간이 요구 사항, 긴급 성 또는 둘 다에 따라 일반적으로 프로젝트 당 1-4 주 범위 인 꽤 시간이 제한된 작업 환경을 갖춘 솔로 개발자입니다. 주어진 시간에 나는 약 3-4 개의 프로젝트를 처리하며, 일부는 서로 겹치는 타임 라인을 가지고 있습니다.

예상대로 코드 품질이 떨어집니다. 또한 공식적인 테스트는 없습니다. 일반적으로 시스템이 다소 파손될 때까지 시스템을 걷는 것으로 내려갑니다. 결과적으로, 많은 양의 버그가 프로덕션으로 빠져 나가서 수정해야하고 다른 프로젝트를 다시 설정해야합니다.

이것이 바로 단위 테스트가 시작되는 곳입니다. 올바르게 수행되면 프로덕션으로 빠져 나간 버그는 최소화해야합니다. 다른 한편으로, 필기 시험은 상당한 시간이 걸릴 수 있으며, 시간 제한이있는 프로젝트와 같은 경우에는 좋지 않습니다.

문제는 테스트되지 않은 코드에 대해 단위 테스트 코드를 작성하는 데 시차가 얼마나되는지, 프로젝트 범위가 넓어 질수록 그 시차가 어떻게 확장됩니까?

나중에 테스트할수록 테스트 작성 비용이 더 많이 듭니다.

버그 수명이 길수록 수정 비용이 많이 듭니다.

반품 감소 법에 따라 버그가 없는지 망각으로 시험 할 수 있습니다.

부처는 중간 길의 지혜를 가르쳤다. 시험은 좋습니다. 좋은 것이 너무 많습니다. 열쇠는 균형이 맞지 않을 때 알 수 있습니다.

테스트없이 작성하는 모든 코드 줄은 코드를 작성하기 전에 테스트를 작성했을 때보 다 나중에 테스트를 추가하는 데 훨씬 많은 비용이 듭니다.

테스트가없는 모든 코드 줄은 디버깅 또는 재 작성이 훨씬 더 어려워집니다.

작성하는 모든 테스트에는 시간이 걸립니다.

모든 버그는 수정하는 데 시간이 걸립니다.

충실한 사람은 먼저 실패한 테스트를 작성하지 않고 한 줄의 코드를 작성하지 말라고 지시합니다. 테스트를 통해 예상 한 동작을 얻을 수 있습니다. 테스트에서 동작이 동일하다는 것이 입증되므로 나머지 시스템에 영향을 줄 염려없이 코드를 빠르게 변경할 수 있습니다.

테스트에 기능이 추가되지 않는다는 사실과 비교하여 모든 것을 평가해야합니다. 생산 코드는 기능을 추가합니다. 그리고 기능은 청구서를 지불하는 것입니다.

실용적으로 말하면, 나는 도망 갈 수있는 모든 테스트를 추가합니다. 나는 시험 시청에 찬성하는 의견을 무시합니다. 내가 생각하는 것을하기 위해 코드를 신뢰조차하지 않습니다. 나는 테스트를 믿습니다. 그러나 나는 가끔 우박 Mary를 던지고 운이 좋은 것으로 알려져 있습니다.

그러나 많은 성공적인 코더는 TDD를 수행하지 않습니다. 그렇다고 테스트하지 않는다는 의미는 아닙니다. 그들은 모든 코드 라인에 대해 자동 테스트가 필요하다고 강박 적으로 주장하지 않습니다. 밥 삼촌조차도 자신의 UI를 테스트하지 않는다는 것을 인정합니다. 또한 모든 로직을 UI 밖으로 옮기라고 주장합니다.

축구 비유 (미식 축구)로서 TDD는 좋은 지상 게임입니다. 코드 더미를 작성하고 그것이 작동하기를 희망하는 수동 테스트는 지나가는 게임입니다. 어느 쪽이든 능숙 할 수 있습니다. 둘 다 할 수 없다면 당신의 경력은 플레이 오프를 만들지 않을 것입니다. 언제 각각을 고를 지 배울 때까지 슈퍼 볼을 만들지 않습니다. 그러나 당신이 특정한 방향으로 조금씩 움직여야한다면 : 공무원의 전화는 내가 지나갈 때 더 자주 저를 거스 릅니다.

TDD를 시험해보고 싶다면 직장에서하기 전에 연습하는 것이 좋습니다. TDD는 반쯤, 반은 반으로, 반은 엉덩이를 존중하는 것이 큰 이유입니다. 한 잔의 물을 다른 잔에 붓는 것과 같습니다. 커밋하지 않고 신속하고 완전하게 수행하면 테이블 전체에 물이 뚝뚝 떨어집니다.

나는 나머지 답변에 동의하지만 시차 질문에 직접 대답합니다.

Roy Osherove 는 자신의 저서 The Art of Unit Testing, Second Edition 200 페이지에서 한 팀이 테스트했지만 다른 팀은 그렇지 않은 두 명의 다른 클라이언트에 대해 비슷한 팀 (기술적 현명한)으로 비슷한 규모의 프로젝트를 구현하는 사례 연구를 수행했습니다.

그의 결과는 다음과 같습니다.

따라서 프로젝트가 끝나면 시간과 버그가 줄어 듭니다. 물론 이것은 프로젝트의 규모에 달려 있습니다.

"실제 환경"에서 이것을 연구 한 것은 단 하나 뿐입니다 . 테스트 중심 개발을 통한 품질 개선 실현 : 4 개의 산업 팀의 결과 및 경험 . 합리적인 방식으로이 작업을 수행하는 것은 비용이 많이 듭니다. 기본적으로 유사한 팀과 동일한 소프트웨어를 두 번 (또는 이상적으로는 더 자주) 개발 한 다음 하나를 제외하고 모두 버려야하기 때문입니다.

연구 결과는 개발 시간이 15 % -35 % (TDD 비평가들에 의해 종종 인용되는 2 배 수치에 가까운 곳)와 40 % -90 %에서 출시 전 결함 밀도의 감소 사이에서 증가했습니다 (! ). 모든 팀은 TDD에 대한 사전 경험이 없었기 때문에 시간의 증가가 학습에 적어도 부분적으로 기인 할 수 있다고 가정 할 수 있으므로 시간이 지남에 따라 더 줄어들 수 있지만, 연구에 의해 평가되지는 않았습니다.

이 연구는 TDD에 관한 것이며 귀하의 질문은 매우 다른 단위 테스트에 관한 것이지만 내가 찾을 수있는 가장 가까운 것입니다.

잘 수행하면 추가 버그의 이점을 고려하지 않아도 단위 테스트로 개발하는 것이 더 빠를 수 있습니다.

사실, 나는 코드가 컴파일되는 즉시 코드가 작동하도록하기에 충분한 코더가 아닙니다. 코드를 작성 / 수정할 때 코드가 생각했던대로 작동하는지 확인하기 위해 코드를 실행해야합니다. 하나의 프로젝트에서 이것은 다음과 같이 보입니다.

1. 코드 수정
2. 응용 프로그램 컴파일
3. 응용 프로그램 실행
4. 응용 프로그램에 로그인
5. 창을 엽니 다
6. 해당 창에서 항목을 선택하여 다른 창을여십시오.
7. 해당 창에서 일부 컨트롤을 설정하고 버튼을 클릭하십시오

그리고 물론, 결국에는 실제로 제대로 얻기 위해 몇 번의 왕복 여행이 필요했습니다.

이제 단위 테스트를 사용하면 어떻게됩니까? 그런 다음 프로세스는 다음과 같습니다.

1. 테스트 작성
2. 테스트를 실행하고 예상대로 실패하는지 확인
3. 코드 작성
4. 테스트를 다시 실행하십시오. 테스트 통과

수동으로 응용 프로그램을 테스트하는 것이 더 쉽고 빠릅니다. 나는 여전히 수동으로 응용 프로그램을 실행해야하므로 (실제로 전혀 작동하지 않는 작업을 시작할 때 어리석은 것처럼 보이지는 않지만) 대부분의 경우 이미 꼬임 문제를 해결했습니다. 그 시점에서 확인합니다. 필자는 일반적으로 저장할 때 테스트를 자동으로 다시 실행하는 프로그램을 사용하여이 루프를 더욱 엄격하게 만듭니다.

그러나 이것은 테스트하기 쉬운 코드 기반 작업에 달려 있습니다. 많은 프로젝트, 심지어 많은 테스트를 거친 프로젝트조차도 쓰기 테스트를 어렵게 만듭니다. 그러나 작업을 수행하면 수동 테스트보다 자동화 된 테스트를 통해 테스트하기 쉬운 코드 기반을 가질 수 있습니다. 또한 자동화 된 테스트를 계속 유지하고 계속 실행하여 회귀를 방지 할 수 있습니다.

이미 많은 답변이 있음에도 불구하고 다소 반복적이며 다른 방식을 취하고 싶습니다. 단위 테스트는 비즈니스 가치 를 높이는 경우에만 가치가 있습니다. 테스팅을위한 테스트 (사소한 또는 타당성 테스트) 또는 임의의 메트릭 (코드 범위와 같은)에 도달하는 것은화물 컬트 프로그래밍입니다.

테스트는 작성하는 데 걸리는 시간뿐만 아니라 유지 관리 비용도 많이 듭니다. 테스트하는 코드와 동기화 상태를 유지해야합니다. 그렇지 않으면 가치가 없습니다. 모든 변경에 대해 실행하는 데 드는 시간 비용은 말할 것도 없습니다. 이는 계약을 깨는 사람 (또는 진정으로 필요한 것을하지 않는 것에 대한 변명)이 아니라 비용-편익 분석에 반영되어야합니다.

따라서 함수 / 방법을 테스트할지 여부 (또는 어떤 종류의)를 결정할 때 물어볼 질문은 '이 테스트로 어떤 최종 사용자 가치를 창출 / 보호하고 있습니까?' 당신이 그 질문에 대답 할 수 없다면, 머리 꼭대기에서 , 그 테스트는 글쓰기 / 유지 비용이 들지 않습니다. (또는 당신은 인 문제 영역, 이해가 안 waaaay를 테스트의 부족보다 더 큰 문제를).

http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

사람과 작업하는 코드의 복잡성과 모양에 따라 다릅니다.

저에게 대부분의 프로젝트에서 단위 테스트 작성은 약 25 % 더 빨리 작업을 수행한다는 것을 의미합니다. 예, 심지어 시험을 작성할 시간도 포함합니다.

중요한 것은 코드를 작성할 때 소프트웨어가 수행 되지 않기 때문 입니다. 고객에게 배송 할 때 완료되며 고객에게 만족합니다. 단위 테스트는 대부분의 버그를 파악하고 디버깅을 위해 대부분의 버그를 격리하며 코드가 좋다는 확신을 얻는 가장 효율적인 방법입니다. 어쨌든 그런 일을해야 하므로 잘해야 합니다.

문제는 테스트되지 않은 코드에 대해 단위 테스트 코드를 작성하는 데 시차가 얼마나되는지, 프로젝트 범위가 넓어 질수록 그 시차가 어떻게 확장됩니까?

새로운 기능을 추가하거나 기존 구현을 리팩토링 할 때마다 이전에 테스트 한 내용을 다시 테스트하여 여전히 작동하는지 확인해야하기 때문에 프로젝트의 수명이 길어질수록 문제가 악화됩니다. 따라서 장기 (수년) 프로젝트의 경우 기능을 테스트 할뿐만 아니라 100 회 이상 다시 테스트해야 할 수도 있습니다. 이러한 이유로 자동화 된 테스트를 통해 이점을 얻을 수 있습니다 . 그러나 IMO는 자동화 된 단위 테스트보다는 자동화 된 시스템 테스트 인 경우에 충분합니다.

두 번째 문제는 버그가 일찍 발견되지 않으면 버그를 찾아 수정하기가 더 어렵다는 것입니다. 예를 들어 시스템에 버그가 있고 최신 변경을하기 전에 완벽하게 작동했다는 것을 알고 있다면 최신 변경 사항에주의를 기울여 버그가 어떻게 도입되었는지 알 수 있습니다. 그러나 최근 변경하기 전에 시스템이 제대로 작동하지 않았다면 (최근 변경 전에 시스템이 올바르게 테스트되지 않았기 때문에) 버그가 어디에나있을 수 있습니다.

위의 내용은 특히 깊은 코드에 적용되며 얕은 코드에는 적용되지 않습니다. 예를 들어 새 페이지가 기존 페이지에 영향을 미치지 않는 새 웹 페이지 추가.

결과적으로, 많은 양의 버그가 프로덕션으로 빠져 나가서 수정해야하고 다른 프로젝트를 다시 설정해야합니다.

내 경험상 받아 들일 수 없으므로 잘못된 질문을하고 있습니다. 테스트를 통해 개발 속도를 높일 수 있는지 묻는 대신 개발에 버그가없는 것이 무엇인지 묻어 야합니다.

더 좋은 질문은 다음과 같습니다.

• 단위 테스트가 올바른 종류의 테스트입니까, "생산중인 버그의 상당 부분"을 피해야합니까?
• 권장하거나 다른 품질 관리 / 개선 메커니즘 (단위 테스트 제외)이 있습니까?

학습은 2 단계 과정입니다. 충분히 잘 배우고 더 빨리 배우십시오.

다른 답변에는 언급되지 않은 일부 측면을 고려해야합니다.

• 추가 혜택 / 추가 비용은 단위 테스트 작성 경험에 따라 달라집니다
  • 첫 번째 단위 테스트 프로젝트를 통해 많은 것을 배워야하고 많은 실수를했기 때문에 추가 비용이 발생했습니다.
  • tdd에 대한 10 년간의 경험을 바탕으로 테스트를 미리 작성하려면 25 % 더 많은 코딩 시간이 필요합니다.
• 더 많은 tdd-moduls를 사용하면 여전히 수동 GUI 테스트 및 통합 테스트가 필요합니다.
• tdd는 처음부터 완료되었을 때만 작동합니다.
  • 기존의 성장한 프로젝트에 tdd를 적용하는 것은 비용이 많이 들고 복잡합니다. 그러나 회귀 테스트를 대신 구현할 수 있습니다.
• 자동화 된 테스트 (단위 테스트 및 다른 종류의 테스트)는 작동을 유지하기 위해 메인 테 나스 const가 필요합니다.
  • 복사 및 붙여 넣기를 통해 테스트를 작성하면 테스트 코드 유지 보수 비용이 많이들 수 있습니다.
  • 경험이 증가함에 따라 테스트 코드는 모듈화되고 유지 관리하기가 더 쉬워졌습니다.
• 경험이 커지면 자동화 된 테스트를 만들 가치가있을 때와 그렇지 않을 때의 느낌을 얻게됩니다.
  • 예를 들어 간단한 getter / setter / wrapper를 unittest하면 큰 이점이 없습니다.
  • 나는 GUI를 통해 자동 테스트를 작성하지 않습니다
  • 비즈니스 계층을 테스트 할 수 있는지 확인합니다.

요약

tdd로 시작할 때, "시간이 제한된 작업 환경"에있는 한, 특히 "비싸고 쓸모없는 사람을 없애라는"영리한 관리자 "가 있다면"비용보다 더 많은 혜택 "상태에 도달하기가 어렵습니다 테스트 물건 "

참고 : "단위 테스트"란 "모듈화 된 테스트 모듈"을 의미합니다.

참고 : "회귀 테스트"란

• 출력 텍스트를 생성하는 코드를 작성하십시오.
• 생성 결과가 여전히 동일하지 않은지 확인하는 "회귀 테스트"코드를 작성하십시오.
• 회귀 테스트는 결과가 변경 될 때마다 알려줍니다 (괜찮거나 새로운 버그의 지표 일 수 있음)
• "회귀 테스트"라는 아이디어는 승인 테스트와 유사합니다.
  • ... 결과의 스냅 샷을 작성하고 변경되지 않았 음을 확인합니다.

대부분의 작업을 처리하는 사람들과 같은 프로그래머는 실제로 완료하는 데 걸리는 시간을 과소 평가합니다. 이를 염두에두고 실제로 테스트 할 때 많은 양의 코드를 작성하는 데 소비 할 수있는 시간으로 테스트를 작성하는 데 10 분을 소비 할 수 있습니다. 테스트하는 동안 수행 한 것과 동일한 기능 이름 및 매개 변수가 나오는 데 소비했을 것입니다. . 이것은 TDD 시나리오입니다.

시험을 쓰지 않는 것은 신용 카드를 갖는 것과 매우 비슷합니다. 우리는 더 많이 쓰거나 더 많은 코드를 쓰는 경향이 있습니다. 더 많은 코드에는 더 많은 버그가 있습니다.

전체 코드 범위를 갖거나 전혀 적용하지 않기로 결정하는 대신 응용 프로그램의 중요하고 복잡한 부분에 초점을 맞추고 테스트를 수행하는 것이 좋습니다. 뱅킹 앱에서는이자가 계산 될 수 있습니다. 엔진 진단 도구에는 복잡한 교정 프로토콜이있을 수 있습니다. 프로젝트를 진행하고 있다면 프로젝트가 무엇인지, 버그가 어디에 있는지 알고있을 것입니다.

천천히 시작하십시오. 판단하기 전에 유창함을 키우십시오. 당신은 항상 멈출 수 있습니다.

TDD 및 기타 테스트 방법론을 홍보하는 프로그래머 보드의 오랜 역사가 있었지만, 나는 그들의 주장을 기억하고 동의하지는 않지만 약간의 뉘앙스를 고려해야 할 추가 사항이 있습니다.

• 상황에 따라 테스트가 편리하고 효율적이지 않습니다. 웹 소프트웨어를 개발하고 전체 UI를 테스트하는 프로그램이 있는지 알려주세요 ... 지금 Excel 매크로를 프로그래밍하고 있습니다. 실제로 VBA에서 테스트 모듈을 개발해야합니까?
• 테스트 소프트웨어를 작성하고 유지 관리하는 것은 단기적으로 계산되는 실제 작업입니다 (장기적으로 비용을 지불합니다). 관련 테스트를 작성하는 것도 전문 지식입니다.
• 팀으로 작업하고 단독으로 작업하는 경우 팀에서 작성하지 않은 코드를 확인, 이해 및 전달해야하므로 동일한 테스트 요구 사항이 아닙니다.

테스트는 훌륭하지만 일찍 테스트하고 게인이 어디 있는지 테스트해야합니다.

TDD의 간과되는 이점은 테스트를 수행 할 때 변경 사항을 적용 할 때 새로운 버그가 발생하지 않도록 보호 역할을한다는 것입니다.

TDD 방식은 처음에는 의심 할 여지없이 시간이 많이 걸리지 만, 코드 를 적게 작성하면 문제가 줄어 듭니다. 물론 당신이 종종 포함하는 모든 종소리와 휘파람은 그것을 코드베이스로 만들지 않을 것입니다.

영화 Swordfish에는 메모리가 제공되는 경우 해커가 총을 들고 머리로 일해야하고 그렇지 않으면 산만하게하는 장면이 있습니다. 요점은 당신의 헤드 스페이스가 코드에 있고 고객이 당신에게 비명을 지르고 다른 우선 순위가 압박되는 상황에서 몇 달이 걸리지 않고 일하는 것이 훨씬 쉽다는 것입니다.

개발자는 나중에 버그를 수정하는 것이 비용이 많이 들지만 이해하기 어렵다는 것을 알고 있습니다. 지금 코딩하는 방식을 코딩하기 위해 하루에 500 달러를 지불하거나 TDD 방식으로 작성한 경우 $ 1000을 지불 할 수 있다면, 두 번째 제안을하는 사람을 물어야합니다. 테스트를 집안일로 보는 것을 멈추고 돈을 절약 할 수있는 시간으로 보는 것이 빠를수록 좋습니다.

나는 당신의 expierience와 관련이 있습니다-우리의 코드베이스는 거의 테스트가 없었으며 대부분 테스트 할 수 없었습니다. 무언가를 개발하는 데 문자 그대로 오랜 시간이 걸렸으며 제작 문제를 해결하는 데 새로운 기능에서 소중한 시간이 걸렸습니다.

부분 재 작성의 경우 모든 핵심 기능에 대한 테스트를 작성하기로 맹세했습니다. 처음에는 시간이 많이 걸렸고 생산성이 눈에 띄게 떨어졌지만 나중에 생산성이 그 어느 때보 다 향상되었습니다.

그 개선의 일부는 생산 버그가 적어 중단이 줄어들 었다는 것입니다.-> 주어진 시간에 더 나은 초점을 받았습니다.

더욱이, 테스트 및 디버그 코드의 완전성은 실제로 지불합니다-테스트 세트는 앱을 시작하고 화면을 탐색하고 무언가를 수행하는 것과 같은 수동 설정을 제외하고는 디버깅 할 수없는 시스템보다 훨씬 우수합니다 ... 아마도 수십 번

그러나 처음에는 생산성이 떨어 지므로 시간 압력이 아직 미미한 일부 프로젝트에서 테스트를 배우십시오. 또한 그린 필드 프로젝트에서 시작해보십시오. 단위 코드 레거시 코드는 매우 어렵고 좋은 테스트 스위트가 어떻게 생겼는지 알 때 도움이됩니다.

이전 답변을 보완하기 위해 테스트는 목적 자체가 아니라는 점을 기억하십시오. 테스트의 목적은 애플리케이션이 예상치 못한 상황 등에서 진화를 통해 예상대로 작동하는 것입니다.

따라서 테스트를 작성한다고해서 엔터티의 모든 끝점에 대한 모든 동작이 증명되는 것은 아닙니다. 이것은 일반적인 오류입니다. 많은 개발자들이 모든 기능 / 객체 / 방법 / 속성 등을 테스트해야한다고 생각합니다. 이는 높은 워크로드와 관련없는 코드 및 테스트로 이어집니다. 이러한 접근 방식은 대부분의 개발자가 전체적인 동작을 인식하지 못하고 상호 작용 영역 만 볼 수있는 대규모 프로젝트에서 일반적입니다.

희소 자원과 테스트를 다룰 때 올바른 접근 방식은 매우 명백하고 상식이지만 일반적으로 공식화되지는 않습니다. 테스트 자원을 높은 수준의 기능에 먼저 투자하고 점차적으로 구체적으로 내려갑니다 . 이것은 어느 시점에서 외로운 개발자로서 단위 테스트뿐만 아니라 기능 / 통합 등에 중점을 둘 것임을 의미합니다. 계획하고 고려 하듯이 시간 자원에 따라 테스트하고 주요 단일 기능으로 점진적으로 테스트하십시오. 고급 테스트는 저수준 / 단일 테스트를 처리하고 보유한 리소스에 따라 테스트 개발 전략을 계획하는 데 필요한 정보를 제공합니다.

예를 들어, 처리 체인을 먼저 블랙 박스로 테스트하려고합니다. 동작이 극단적 인 조건으로 간주되지 않아 체인의 일부 멤버가 실패한 경우이 멤버뿐만 아니라 다른 멤버에서도 기능을 보장하는 테스트를 작성합니다. 그런 다음 제공합니다. 다음주기에서는 때때로 네트워크가 실패하는 것을 감지합니다. 따라서 취약한 모듈에서 이러한 문제를 해결하는 테스트를 작성하십시오. 등등.