단위 테스트 란 무엇입니까? [닫은]

특정 언어로 단위 테스트를하는 방법을 묻는 많은 질문을 보았지만 '무엇을', '왜', '언제'를 묻는 질문은 없었습니다.

• 무엇입니까?
• 그것은 나를 위해 무엇을합니까?
• 왜 사용해야합니까?
• 언제 사용해야합니까?
• 일반적인 함정과 오해는 무엇입니까

단위 테스트는 대략 코드 코드를 테스트 코드와 별도로 테스트하는 것입니다. 떠오르는 장점은 다음과 같습니다.

• 테스트 실행이 자동화되고 반복 가능 해짐
• GUI를 통한 포인트 앤 클릭 테스트보다 훨씬 세부적인 수준에서 테스트 할 수 있습니다.

테스트 코드가 파일에 쓰거나 데이터베이스 연결을 열거 나 네트워크를 통해 무언가를 수행하는 경우 통합 테스트로 더 적절하게 분류됩니다. 통합 테스트는 좋은 것이지만 단위 테스트와 혼동해서는 안됩니다. 단위 테스트 코드는 짧고 달콤하며 실행이 빠릅니다.

단위 테스트를 보는 다른 방법은 먼저 테스트를 작성하는 것입니다. 이것을 TDD (Test-Driven Development)라고합니다. TDD는 다음과 같은 추가 장점을 제공합니다.

• 당신은 투기적인 "나중에 이것을 필요로 할지도 모른다"라는 코드를 작성하지 않습니다.
• 당신이 작성한 코드는 항상 테스트에 의해 커버됩니다
• 테스트를 먼저 작성하면 코드를 호출하는 방법에 대해 생각해야하는데 이는 일반적으로 장기적으로 코드 디자인을 향상시킵니다.

지금 단위 테스트를 수행하지 않는 경우 시작하는 것이 좋습니다. 개념이 그들 사이에 매우 많이 전달 될 수 있기 때문에 실질적으로 모든 xUnit-book이 할 좋은 책을 얻으십시오.

때때로 단위 테스트를 작성하는 것이 어려울 수 있습니다. 그렇게되면 도움이 될 사람을 찾아 "저런 코드를 작성하라"는 유혹에 저항하십시오. 단위 테스트는 설거지와 비슷합니다. 항상 즐겁지는 않지만 은유 적 인 주방을 깨끗하게 유지하고 실제로 깨끗하게 만들고 싶습니다. :)

편집 : 하나의 오해가 떠 오릅니다.하지만 그것이 일반적인지 확실하지 않습니다. 프로젝트 관리자가 단위 테스트로 인해 팀이 모든 코드를 두 번 작성했다고 말합니다. 그것이 그렇게 보이고 느껴지면, 잘못하고있는 것입니다. 테스트를 작성하면 일반적으로 개발 속도가 빨라질뿐만 아니라, 그렇지 않은 편리한 "지금 완료되었습니다"표시를 제공합니다.

나는 Dan과 동의하지 않습니다 (더 나은 선택은 대답하지 않을 수도 있지만) ...

단위 테스트는 시스템의 동작 및 기능을 테스트하기위한 코드 작성 프로세스입니다.

분명히 테스트는 코드의 품질을 향상 시키지만 단위 테스트의 피상적 인 이점 일뿐입니다. 실제 이점은 다음과 같습니다.

1. 동작 (리팩토링)을 변경하지 않으면 서 기술 구현을보다 쉽게 ​​변경할 수 있습니다. 제대로 테스트 한 코드는 눈에 띄지 않고 아무것도 깨뜨리지 않고 공격적으로 리팩터링 / 정리할 수 있습니다.
2. 동작을 추가하거나 수정할 때 개발자에게 확신을 제공하십시오.
3. 코드를 문서화하십시오
4. 밀접하게 결합 된 코드 영역을 나타냅니다. 밀접하게 결합 된 코드를 단위 테스트하기가 어렵습니다.
5. API를 사용하고 초기에 어려움을 찾을 수있는 수단 제공
6. 응집력이 좋지 않은 메소드와 클래스를 나타냅니다.

유지 보수 가능하고 우수한 품질의 제품을 고객에게 제공하려면 관심사가 있기 때문에 단위 테스트를 수행해야합니다.

실제 동작을 모델링하는 시스템 또는 시스템의 일부에 사용하는 것이 좋습니다. 즉, 엔터프라이즈 개발에 특히 적합합니다. 버리기 / 유틸리티 프로그램에는 사용하지 않겠습니다. 테스트하기 어려운 시스템의 일부에는 사용하지 않을 것입니다 (UI는 일반적인 예이지만 항상 그런 것은 아닙니다)

가장 큰 함정은 개발자가 너무 큰 단위를 테스트하거나 메소드를 단위로 간주한다는 것입니다. 제어 역전 (Inversion of Control)을 이해하지 못하는 경우 특히 그렇습니다.이 경우 단위 테스트는 항상 종단 간 통합 테스트로 바뀝니다. 단위 테스트는 개별 동작을 테스트해야하며 대부분의 방법에는 많은 동작이 있습니다.

가장 큰 오해는 프로그래머가 테스트해서는 안된다는 것입니다. 나쁘거나 게으른 프로그래머 만이 그것을 믿습니다. 지붕을 짓는 사람이 테스트하지 않습니까? 심장 판막을 교체하는 의사가 새 판막을 검사하지 않아야합니까? 프로그래머 만이 자신의 코드가 의도 한대로 작동하는지 테스트 할 수 있습니다 (QA는 프로그래머가 의도하지 않은 일을하도록 지시를 받았을 때 코드가 동작하는 방식과 클라이언트가 승인 테스트를 수행 할 수있는 방식을 테스트 할 수 있음) 고객이 지불 한 금액

"새로운 프로젝트를 열고이 특정 코드를 테스트하는 것"과 반대로 단위 테스트의 주요 차이점은 자동화 되어 반복 가능 하다는 것 입니다.

코드를 수동으로 테스트하면 코드가 현재 상태에서 완벽하게 작동하고 있음을 확신 할 수 있습니다 . 그러나 일주일 후에 약간 수정하면 어떨까요? 당신은 할 때마다 손으로 다시 재시험 기꺼이 아무것도 코드의 변화? 아마 아닐 것 :-(

당신이 수 있다면 몇 초 내에 한 번의 클릭으로, 동일한 방식으로, 당신의 검사 결과 언제든지 실행 , 그들은 것입니다 문제가 생겼 때마다 즉시을 보여줍니다. 또한 단위 테스트를 자동화 된 빌드 프로세스에 통합하는 경우 완전히 관련이없는 것처럼 보이는 변경이 코드베이스의 먼 부분에 문제가 발생한 경우에도 버그를 경고합니다. 특정 기능을 다시 테스트해야합니다.

이것이 수동 테스트보다 단위 테스트의 주요 이점입니다. 그러나 더 많은 것이 있습니다.

• 단위 테스트 는 개발 피드백 루프를 획기적으로 단축시킵니다 . 별도의 테스트 부서를 사용하면 코드에 버그가 있음을 알기까지 몇 주가 소요될 수 있습니다. 버그를 찾아 수정하십시오. 단위 테스트를 사용하는 OTOH, 피드백주기는 초 단위로 측정되며 버그 수정 프로세스는 일반적으로 "oh sh * t, 해당 조건을 확인하는 것을 잊었습니다":-)
• 단위 테스트 는 코드의 행동을 효과적으로 문서화 합니다
• 단위 테스트를 통해 설계 선택을 재평가해야 하므로 더 단순하고 깔끔한 설계

단위 테스트 프레임 워크를 사용하면 테스트를 쉽게 작성하고 실행할 수 있습니다.

나는 대학에서 단위 테스트를 배운 적이 없었고 그것을 "얻는"데 시간이 걸렸다. 나는 그것에 대해 읽고, "아, 맞아, 자동 테스트, 그것은 멋지다"고 생각하고 잊어 버렸습니다.

요점을 이해하기까지 시간이 조금 더 걸렸습니다. 큰 시스템에서 작업 중이고 작은 모듈을 작성한다고 가정 해 봅시다. 그것은 컴파일하고, 당신은 그것의 페이스를 통과시키고, 훌륭하게 작동하며, 다음 작업으로 넘어갑니다. 9 개월 동안 줄을 잃고 두 버전이 지나면 다른 사람이 프로그램의 관련이없는 것으로 변경되어 모듈이 손상됩니다. 더 나쁜 것은 변경 사항을 테스트하고 코드가 작동하지만 모듈을 테스트하지는 않는다는 것입니다. 지옥, 그들은 당신의 모듈 이 존재한다는 것을 알지 못할 수도 있습니다 .

이제 문제가 생겼습니다. 깨진 코드가 트렁크에 있고 아무도 모릅니다. 가장 좋은 경우는 내부 테스터가 배송 전에 발견하지만 게임 후반에 코드를 수정하는 것은 비용이 많이 든다는 것입니다. 그리고 내부 테스터가 그것을 찾지 못하면 ... 매우 비싸 질 수 있습니다.

해결책은 단위 테스트입니다. 코드를 작성할 때 문제가 생길 수 있습니다.하지만 문제는 손으로 할 수 있습니다. 실제로는 완전히 다른 프로젝트를 진행할 때 9 개월 동안 문제가 발생하지만 여름 인턴은 해당 매개 변수가 알파벳 순서로 정렬되면 더 깔끔해 보일 것이라고 생각합니다. 당신은 되돌아가는 길을 썼고, 누군가 매개 변수 순서를 다시 바꿀 때까지 인턴에서 물건을 던졌습니다. 이것이 단위 테스트의 "이유"입니다. :-)

단위 테스트와 TDD에 대한 철학적 전문가들에 대한 지식은 TDD 깨달음으로가는 길에서 나의 첫 번째 단계에서 나를 놀라게 한 주요 "전구"관찰 중 일부입니다 (원본 또는 뉴스는 아닙니다) ...

1. TDD는 두 배의 코드를 쓰는 것을 의미하지 않습니다. 테스트 코드는 일반적으로 작성하기가 매우 빠르고 어렵지 않으며 디자인 프로세스의 핵심 부분입니다.

2. TDD는 코딩을 언제 중단해야하는지 깨닫는 데 도움이됩니다! 당신의 테스트는 당신이 지금까지 충분히 해왔음을 확신하고 조정을 멈추고 다음 단계로 넘어갈 수 있습니다.

3. 테스트와 코드는보다 나은 코드를 달성하기 위해 함께 작동합니다. 코드가 잘못되었거나 버그가있을 수 있습니다. 테스트가 나쁘거나 버그가있을 수 있습니다. TDD에서 당신은 둘 다 나쁜 / 버그가 상당히 낮을 가능성에 대해 뱅킹하고 있습니다. 종종 수정이 필요한 테스트이지만 여전히 좋은 결과입니다.

4. TDD는 코딩 변비에 도움이됩니다. 당신이 할 일이 너무 많다는 느낌을 어디에서 시작해야할지 거의 알지 못합니까? 금요일 오후입니다. 몇 시간 만 더 미루면 ... TDD를 사용하면 자신이해야 할 일을 매우 신속하게 해결할 수 있으며 코딩이 빠르게 진행됩니다. 또한 실험실 쥐처럼 우리 모두는 그 큰 녹색 빛에 반응하고 다시보기 위해 더 열심히 일한다고 생각합니다!

5. 비슷한 맥락에서 이러한 디자이너 유형은 작업중인 것을 볼 수 있습니다. 그들은 주스 / 담배 / 아이폰 휴식을 위해 방황하고 모니터로 돌아와서 그들이 어디로 향했는지 시각적으로 알 수 있습니다. TDD는 우리에게 비슷한 것을 제공합니다. 인생이 개입 할 때 우리가 어디로 가야하는지 쉽게 알 수 있습니다

6. 나는 파울러가 말했다 : "완전히 실행되는 불완전한 테스트는 전혀 작성되지 않은 완벽한 테스트보다 훨씬 낫다"고 말했다. 나는 이것을 코드 작성의 나머지 부분이 불완전하게 불완전하더라도 가장 유용하다고 생각되는 테스트를 작성할 수있는 권한을 부여하는 것으로 해석합니다.

7. TDD는 모든 종류의 놀라운 방법으로 도움을줍니다. 좋은 단위 테스트는 무엇을해야하는지 문서화하는 데 도움이되며, 한 프로젝트에서 다른 프로젝트로 코드를 마이그레이션하고 테스트하지 않은 동료보다 우월한 느낌을 줄 수 있습니다. :)

이 프레젠테이션 은 모든 맛있는 선량 테스트에 대한 훌륭한 소개입니다.

Gerard Meszaros의 xUnit Testing Patterns 책을 추천하고 싶습니다. 크기는 크지 만 단위 테스트에 대한 훌륭한 리소스입니다. 다음은 그의 웹 사이트에 대한 링크로 유닛 테스트의 기본 사항을 설명합니다. http://xunitpatterns.com/XUnitBasics.html

단위 테스트를 사용하여 시간을 절약합니다.

비즈니스 로직 (또는 데이터 액세스)을 구축 할 때 테스트 기능은 종종 아직 완료되지 않았거나 완료되지 않은 많은 화면에 물건을 입력하는 것을 포함 할 수 있습니다. 이러한 테스트를 자동화하면 시간이 절약됩니다.

저에게 단위 테스트는 일종의 모듈화 된 테스트 하네스입니다. 일반적으로 공개 기능 당 하나 이상의 테스트가 있습니다. 다양한 행동을 다루기 위해 추가 테스트를 작성합니다.

코드를 개발할 때 생각한 모든 특수 사례는 단위 테스트의 코드에 기록 될 수 있습니다. 단위 테스트는 코드 사용 방법에 대한 예제 소스이기도합니다.

새 코드가 단위 테스트에서 무언가를 깨뜨린 다음 코드를 체크인하고 일부 프론트 엔드 개발자에게 문제가 있음을 발견하는 것이 훨씬 더 빠릅니다.

데이터 액세스 테스트를 위해 변경이 없거나 자체적으로 정리 된 테스트를 작성하려고합니다.

단위 테스트로 모든 테스트 요구 사항을 해결할 수는 없습니다. 또한 개발 시간을 절약하고 애플리케이션의 핵심 부분을 테스트 할 수 있습니다.

이게 내 취향이야 단위 테스트는 실제 소프트웨어가 의도 한 기능을 수행하는지 확인하기 위해 소프트웨어 테스트를 작성하는 연습입니다. 이것은 시작 의 JUnit 자바 세계와 함께뿐만 아니라 PHP의 모범 사례가되었다 SimpleTest 및 phpunit을 . 익스트림 프로그래밍의 핵심 사례이며 편집 후에도 소프트웨어가 의도 한대로 작동하는지 확인할 수 있습니다. 테스트 범위가 충분하면 다른 문제가 발생할 염려없이 주요 리팩토링, 버그 수정 또는 기능을 빠르게 추가 할 수 있습니다.

모든 단위 테스트가 자동으로 실행될 때 가장 효과적입니다.

단위 테스트는 일반적으로 OO 개발과 관련이 있습니다. 기본 아이디어는 코드 환경을 설정하고 연습하는 스크립트를 만드는 것입니다. 어설 션을 작성하고 원하는 출력을 지정한 다음 위에서 언급 한 것과 같은 프레임 워크를 사용하여 테스트 스크립트를 실행합니다.

프레임 워크는 코드에 대해 모든 테스트를 실행 한 다음 각 테스트의 성공 또는 실패를 다시보고합니다. phpUnit은 기본적으로 Linux 명령 행에서 실행되지만 사용 가능한 HTTP 인터페이스가 있습니다. SimpleTest는 본질적으로 웹 기반이며 IMO를 시작하고 실행하는 것이 훨씬 쉽습니다. xDebug와 함께 phpUnit은 일부 사람들에게 유용한 코드 범위에 대한 자동화 된 통계를 제공 할 수 있습니다.

일부 팀은 변경 사항을 커밋 할 때마다 단위 테스트가 자동으로 실행되도록 서브 버전 저장소에서 후크를 작성합니다.

단위 테스트는 응용 프로그램과 동일한 저장소에 보관하는 것이 좋습니다.

TDD를 사용하여 프로젝트를 개발하려는 경우 NUnit , xUnit 또는 JUnit 과 같은 라이브러리 는 필수입니다.Kent Beck이 대중화 한 접근법을 .

TDD (Test Driven Development) 소개 또는 Kent Beck의 책 Test Driven Development : By By를 읽을 수 있습니다 . .

그런 다음 테스트에서 코드의 "좋은"부분을 커버하는지 확인하려면 NCover , JCover , PartCover 등과 같은 소프트웨어를 사용할 수 있습니다 . 코드의 적용률을 알려줍니다. TDD에 능숙한 정도에 따라 충분히 연습했는지 알 수 있습니다. :)

단위 테스트는 코드 단위가 의존하는 인프라가 필요없는 코드 단위 (예 : 단일 기능)를 테스트하는 것입니다. 즉, 분리하여 테스트하십시오.

예를 들어 테스트중인 기능이 데이터베이스에 연결하고 업데이트를 수행하는 경우 단위 테스트에서 해당 업데이트를 수행하지 않을 수 있습니다. 통합 테스트 인 경우에는 그렇지 않지만이 경우에는 그렇지 않습니다.

따라서 단위 테스트는 데이터베이스 업데이트의 부작용없이 테스트중인 "기능"에 포함 된 기능을 연습합니다.

함수가 데이터베이스에서 일부 숫자를 검색 한 다음 표준 편차 계산을 수행했다고 가정하십시오. 여기서 무엇을 테스트하려고합니까? 표준 편차가 올바르게 계산되었거나 데이터베이스에서 데이터가 반환됩니까?

단위 테스트에서는 표준 편차가 올바르게 계산되었는지 테스트하려고합니다. 통합 테스트에서 표준 편차 계산 및 데이터베이스 검색을 테스트하려고합니다.

단위 테스트는 응용 프로그램 코드를 테스트하는 코드를 작성하는 것입니다.

이름 의 단위 부분은 한 번에 작은 코드 단위 (예 : 한 가지 방법)를 테스트하려는 의도입니다.

xUnit은이 테스트에 도움을주기 위해 존재합니다.이를 지원하는 프레임 워크입니다. 그 중 일부는 테스트 실패와 통과 테스트를 알려주는 자동화 된 테스트 러너입니다.

또한 각 테스트에 필요한 공통 코드를 미리 설정하고 모든 테스트가 완료되면 분리 할 수있는 기능이 있습니다.

전체 try catch 블록을 직접 쓰지 않고도 예상 예외가 발생했는지 확인하는 테스트를 할 수 있습니다.

이해하지 못하는 점은 NUnit과 같은 단위 테스트 프레임 워크 가 중소 규모의 테스트를 자동화하는 데 도움이 될 것 입니다. 일반적으로 버튼을 클릭하여 GUI에서 테스트를 실행할 수 있습니다 ( 예를 들어 NUnit 의 경우 ) 진행률 표시 줄이 녹색으로 유지됩니다. 빨간색으로 바뀌면 프레임 워크에 어떤 테스트가 실패했으며 정확히 무엇이 잘못되었는지 표시됩니다. 일반적인 단위 테스트에서는 종종 어설 션을 사용합니다. 예를 들어 Assert.AreEqual(expectedValue, actualValue, "some description")두 값이 같지 않으면 "일부 설명 : 예상 <expectedValue>이지만 <actualValue>"라는 오류가 표시됩니다.

결론적으로 단위 테스트는 개발자에게 테스트를보다 빠르고 편안하게 해줄 것입니다. 동일한 코드에서 다른 개발자의 빌드 프로세스를 중단하지 않도록 새 코드를 커밋하기 전에 모든 단위 테스트를 실행할 수 있습니다.

Testivus를 사용하십시오 . 당신이 알아야 할 것은 바로 거기에 있습니다 :)

단위 테스트는 구현하려는 기능 또는 모듈이 예상대로 작동하는지 (필수), 경계 조건 및 유효하지 않은 입력과 같은 시나리오에서 작동하는 방식을 확인하는 방법입니다.

xUnit , NUnit , mbUnit 등은 테스트 작성에 도움이되는 도구입니다.

테스트 주도 개발은 단위 테스트라는 용어를 대체했습니다. 오래된 타이머로 더 일반적인 정의를 언급하겠습니다.

단위 테스트는 또한 더 큰 시스템에서 단일 구성 요소를 테스트하는 것을 의미합니다. 이 단일 구성 요소는 dll, exe, 클래스 라이브러리 등일 수 있습니다. 다중 시스템 응용 프로그램의 단일 시스템 일 수도 있습니다. 따라서 궁극적으로 단위 테스트는 더 큰 단일 시스템이라고 부르는 모든 것을 테스트하는 것입니다.

그런 다음 모든 구성 요소가 함께 작동하는 방식을 테스트하여 통합 또는 시스템 테스트로 넘어갑니다.

우선, 단위 테스트 나 다른 종류의 자동화 테스트 (통합,로드, UI 테스트 등)에 대해 말하건, 제안한 것과의 주요 차이점은 자동화되고 반복 가능하며 인적 자원이 필요하지 않다는 것입니다 소비 될 것입니다 (= 아무도 시험을 수행 할 필요가 없으며, 보통 버튼을 한 번만 누르면 실행됩니다).

FoxForward 2007에서 단위 테스트에 대한 프레젠테이션을했는데 데이터로 작동하는 모든 것을 단위 테스트하지 말라고 들었습니다. 결국 라이브 데이터를 테스트하면 결과를 예측할 수 없으며 라이브 데이터를 테스트하지 않으면 실제로 작성한 코드를 테스트하지 않습니다. 불행히도, 그것은 요즘 내가하는 코딩의 대부분입니다. :-)

최근에 설정을 저장하고 복원하는 루틴을 작성할 때 TDD에서 촬영했습니다. 먼저 스토리지 객체를 생성 할 수 있는지 확인했습니다. 그런 다음 호출해야 할 방법이 있습니다. 그런 다음 전화 할 수있었습니다. 그런 다음 매개 변수를 전달할 수 있습니다. 그런 다음 특정 매개 변수를 전달할 수 있습니다. 그리고 마지막으로 지정된 설정을 저장하고 변경 한 다음 몇 가지 다른 구문으로 복원 할 수 있는지 확인할 때까지.

나는 일상적인 절망이 필요했기 때문에 끝내지 못했지만 좋은 운동이었습니다.

당신은 쓰레기 더미가 주어지고 당신이 새로운 기능이나 코드를 추가하여 현재의 소프트웨어가 집의 집과 같기 때문에 현재 세트를 깨뜨릴 수있는 영원한 정리 상태에 갇힌 것처럼 보이는 경우 어떻게해야합니까? 카드?

그러면 어떻게 단위 테스트를 할 수 있습니까?

당신은 작은 시작합니다. 방금 들어간 프로젝트는 몇 달 전까지 단위 테스트가 없었습니다. 적용 범위가 너무 낮 으면 적용 범위가없는 파일을 선택하고 "테스트 추가"를 클릭하면됩니다.

지금 우리는 최대 40 %가 넘었고, 거꾸로 과일의 대부분을 뽑아 냈습니다.

(최상의 부분은이 낮은 수준의 적용 범위에서도 이미 잘못된 코드를 수행하는 많은 코드 인스턴스를 실행했으며 테스트에서 포착 한 것입니다. 이는 사람들이 더 많은 테스트를 추가하도록 강요하는 큰 동기 부여입니다.)

이것은 왜 유닛 테스트를해야하는지에 대한 답입니다.

아래 3 개의 비디오는 자바 스크립트 단위 테스트를 다루지 만 일반적인 원칙은 대부분의 언어에 적용됩니다.

단위 테스트 : 몇 분 후에 시간이 절약됩니다-Eric Mann- https: //www.youtube.com/watch?v= _UmmaPe8Bzc

JS 단위 테스트 (아주 좋음)-https://www.youtube.com/watch?v= -IYqgx8JxlU

쓰기 시험 가능한 자바 스크립트 - https://www.youtube.com/watch?v=OzjogCFO4Zo

이제는 주제에 대해 배우기 때문에 100 % 정확하지 않을 수 있으며 여기에 설명하는 것보다 더 많은 것이 있지만 단위 테스트에 대한 기본 이해는 테스트 코드를 작성한다는 것입니다. main code) 함수가 필요로하는 입력 (인수)을 사용하여 메인 코드에서 함수를 호출 한 다음 코드가 유효한 반환 값을 가져 오는지 확인합니다. 유효한 값으로 돌아 오면 테스트를 실행하는 데 사용하는 단위 테스트 프레임 워크가 녹색 표시 등 (모두 양호)으로 표시됩니다. 값이 유효하지 않으면 빨간색 표시등이 켜지고 문제를 바로 해결할 수 있습니다. 테스트하지 않고 새 코드를 프로덕션으로 릴리스하면 실제로 오류가 발생하지 않았을 수 있습니다.

따라서 현재 코드를 테스트하고 테스트를 통과하도록 코드를 작성하십시오. 몇 달 후 당신이나 다른 누군가가 메인 코드에서 함수를 수정해야합니다. 이전에 해당 함수에 대한 테스트 코드를 이미 작성 했으므로 이제 다시 실행되고 코더가 함수에 논리 오류를 도입하거나 무언가를 완전히 반환하기 때문에 테스트가 실패 할 수 있습니다 해당 함수가 반환 해야하는 것과 다릅니다. 다시 테스트를 거치지 않으면 다른 코드에도 영향을 미쳐 눈에 띄지 않게 오류를 추적하기 어려울 수 있습니다.

또한 브라우저 페이지에서 코드를 직접 실행하는 대신 코드를 통해 실행하고 테스트하는 컴퓨터 프로그램이 있다는 사실 때문에 시간이 절약됩니다 (자바 스크립트의 단위 테스트). 웹 페이지의 일부 스크립트에서 사용하는 함수를 수정하고 새로운 의도의 목적에 적합하게 작동한다고 가정 해 봅시다. 그러나 인수를 위해 코드에서 다른 함수가 제대로 작동하기 위해 새로 수정 된 함수에 의존하는 다른 함수가 있다고 가정 해 봅시다. 이 종속 기능은 이제 첫 번째 기능의 변경으로 인해 작동을 멈출 수 있지만 컴퓨터에서 자동으로 실행되는 테스트가 없으면 실제로 실행될 때까지 해당 기능에 문제가 있음을 알 수 없습니다. 당신'

다시 말하지만, 응용 프로그램을 개발하는 동안 실행되는 테스트를 수행하면 코딩 할 때 이러한 종류의 문제가 발생합니다. 테스트를 수행하지 않으면 전체 응용 프로그램을 수동으로 수행해야하며 버그를 발견하기가 어려울 수 있습니다. 순진하게 버그를 프로덕션으로 보내고 잠시 후에 친절한 사용자가 버그 보고서를 보냅니다. 테스트 프레임 워크의 오류 메시지만큼 좋지는 않습니다).

주제를 처음 듣고 자신을 생각할 때 혼란 스럽습니다. 내 코드를 아직 테스트하지 않았습니까? 그리고 여러분이 작성한 코드는 이미 "왜 다른 프레임 워크가 필요합니까?"와 같은 방식으로 작동하고 있습니다. 그렇습니다. 이미 코드를 테스트하고 있지만 컴퓨터가 더 잘하고 있습니다. 함수 / 코드 단위에 대해 충분한 테스트를 한 번 작성하면 나머지 코드는 변경 할 때 모든 코드가 여전히 작동하는지 수동으로 확인하는 대신 강력한 CPU에 의해 처리됩니다. 귀하의 코드.

또한 원하지 않는 경우 코드를 단위로 테스트 할 필요는 없지만 버그를 도입 할 가능성이 높아짐에 따라 프로젝트 / 코드 기반이 커지기 시작함에 따라 그 가치가 높아집니다.

일반적으로 단위 테스트 및 TDD를 사용하면 작성중인 소프트웨어에 대한 피드백주기를 단축 할 수 있습니다. 구현이 끝날 때 큰 테스트 단계를 거치지 않고 작성하는 모든 것을 점진적으로 테스트합니다. 이렇게하면 즉시 버그가있을 수있는 곳에서 코드 품질이 크게 향상됩니다.