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

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

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

답변

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

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

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

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

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

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

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

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

답변

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

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

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

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

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

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

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

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

답변

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

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

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

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

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

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

답변

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

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

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

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

답변

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

TDD는 두 배의 코드를 쓰는 것을 의미하지 않습니다. 테스트 코드는 일반적으로 작성하기가 매우 빠르고 어렵지 않으며 디자인 프로세스의 핵심 부분입니다.
TDD는 코딩을 언제 중단해야하는지 깨닫는 데 도움이됩니다! 당신의 테스트는 당신이 지금까지 충분히 해왔음을 확신하고 조정을 멈추고 다음 단계로 넘어갈 수 있습니다.
테스트와 코드는보다 나은 코드를 달성하기 위해 함께 작동합니다. 코드가 잘못되었거나 버그가있을 수 있습니다. 테스트가 나쁘거나 버그가있을 수 있습니다. TDD에서 당신은 둘 다 나쁜 / 버그가 상당히 낮을 가능성에 대해 뱅킹하고 있습니다. 종종 수정이 필요한 테스트이지만 여전히 좋은 결과입니다.
TDD는 코딩 변비에 도움이됩니다. 당신이 할 일이 너무 많다는 느낌을 어디에서 시작해야할지 거의 알지 못합니까? 금요일 오후입니다. 몇 시간 만 더 미루면 … TDD를 사용하면 자신이해야 할 일을 매우 신속하게 해결할 수 있으며 코딩이 빠르게 진행됩니다. 또한 실험실 쥐처럼 우리 모두는 그 큰 녹색 빛에 반응하고 다시보기 위해 더 열심히 일한다고 생각합니다!
비슷한 맥락에서 이러한 디자이너 유형은 작업중인 것을 볼 수 있습니다. 그들은 주스 / 담배 / 아이폰 휴식을 위해 방황하고 모니터로 돌아와서 그들이 어디로 향했는지 시각적으로 알 수 있습니다. TDD는 우리에게 비슷한 것을 제공합니다. 인생이 개입 할 때 우리가 어디로 가야하는지 쉽게 알 수 있습니다
나는 파울러가 말했다 : “완전히 실행되는 불완전한 테스트는 전혀 작성되지 않은 완벽한 테스트보다 훨씬 낫다”고 말했다. 나는 이것을 코드 작성의 나머지 부분이 불완전하게 불완전하더라도 가장 유용하다고 생각되는 테스트를 작성할 수있는 권한을 부여하는 것으로 해석합니다.
TDD는 모든 종류의 놀라운 방법으로 도움을줍니다. 좋은 단위 테스트는 무엇을해야하는지 문서화하는 데 도움이되며, 한 프로젝트에서 다른 프로젝트로 코드를 마이그레이션하고 테스트하지 않은 동료보다 우월한 느낌을 줄 수 있습니다. 🙂

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

답변

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

답변

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

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

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

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

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

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

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