단위 테스트로 무엇을 테스트해야합니까?

나는 대학에서 신입생이고 다음 주 어딘가에 대학을 시작합니다. 우리는 단위 테스트를 보았지만 많이 사용하지는 않았습니다. 모두가 그들에 대해 이야기하기 때문에 아마도 내가해야 할 일이라고 생각했습니다.

문제는 무엇 을 테스트 해야할지 모르겠다는 것 입니다. 일반적인 경우를 테스트해야합니까? 가장자리 사건? 기능이 적절하게 적용되었다는 것을 어떻게 알 수 있습니까?

나는 항상 테스트가 어떤 경우에는 함수가 작동한다는 것을 증명하지만, 그 함수가 작동한다는 것을 증명하는 것은 전혀 쓸모가 없다는 끔찍한 느낌을 가지고 있습니다.

나의 개인적인 철학은 지금까지 :

1. 할 수있는 모든 일의 일반적인 사례를 테스트하십시오. 이것은 약간의 변경을 한 후에 코드가 중단되는 시점을 알려줄 것입니다.
2. 오류가있을 것으로 생각되는 비정상적으로 복잡한 몇 가지 코드의 에지 사례를 테스트하십시오.
3. 버그를 발견 할 때마다 수정하기 전에 테스트 케이스를 작성하여 커버하십시오.
4. 누군가 죽일 시간이있을 때마다 덜 중요한 코드에 엣지 케이스 테스트를 추가하십시오.

지금까지 과다한 답변 중 동등성 분할 및 경계 값 분석 에 대해서는 아직 아무도 다루지 않았습니다 . 다른 모든 대답은 유용하지만 질적이지만 여기서는 정량적 일 수 있습니다. @fishtoaster는 테스트 정량화의 커버를 통해 엿보기에 대한 구체적인 지침을 제공하지만 동등성 분할 및 경계 값 분석을 통해 더 나은 결과를 얻을 수 있습니다.

동등성 파티셔닝 에서는 가능한 모든 입력 세트를 예상 결과에 따라 그룹으로 나눕니다. 한 그룹의 모든 입력은 동등한 결과를 생성하므로 이러한 그룹을 동등성 클래스 라고 합니다 . 동등한 결과가 동일한 결과를 의미 하지는 않습니다 .

간단한 예로 소문자 ASCII 문자를 대문자로 변환해야하는 프로그램을 고려하십시오. 다른 캐릭터는 신원 변환을 거쳐야합니다. 동등성 클래스로 분류 할 수있는 방법은 다음과 같습니다.

| # |  Equivalence class    | Input        | Output       | # test cases |
+------------------------------------------------------------------------+
| 1 | Lowercase letter      | a - z        | A - Z        | 26           |
| 2 | Uppercase letter      | A - Z        | A - Z        | 26           |
| 3 | Non-alphabetic chars  | 0-9!@#,/"... | 0-9!@#,/"... | 42           |
| 4 | Non-printable chars   | ^C,^S,TAB... | ^C,^S,TAB... | 34           |

마지막 열은 모든 테스트 사례를 열거하면 테스트 사례 수를보고합니다. 기술적으로 @fishtoaster의 규칙 1에서는 52 개의 테스트 사례를 포함합니다. 위에 제공된 처음 두 행에 대한 모든 사례는 "일반 사례"에 해당합니다. @fishtoaster의 규칙 2는 위의 행 3과 4에서 일부 또는 전부를 추가합니다. 그러나 동등성 분할 테스트 에서는 각 동등성 클래스에서 하나의 테스트 케이스로 충분합니다. "a"또는 "g"또는 "w"를 선택하면 동일한 코드 경로를 테스트하는 것입니다. 따라서 52 개가 아닌 총 4 개의 테스트 사례가 있습니다.

경계 값 분석 은 약간의 개선을 권장합니다. 본질적으로 동등성 클래스의 모든 구성원이 동등하지는 않다는 것을 제안합니다. 즉, 경계의 값도 자체적으로 테스트 사례에 적합한 것으로 간주해야합니다. (이것에 대한 하나의 쉬운 정당화는 악명 높은 off-by-one error입니다 !) 따라서 각 동등성 클래스에 대해 3 개의 테스트 입력을 가질 수 있습니다. 위의 입력 도메인과 ASCII 값에 대한 지식을 살펴보면 다음과 같은 테스트 케이스 입력을 얻을 수 있습니다.

| # | Input                | # test cases |
| 1 | a, w, z              | 3            |
| 2 | A, E, Z              | 3            |
| 3 | 0, 5, 9, !, @, *, ~  | 7            |
| 4 | nul, esc, space, del | 4            |

(원래 동등성 클래스 묘사를 다시 생각하고 싶을 수있는 3 개 이상의 경계 값을 얻 자마자 이것은 간단하게 수정하기 위해 되돌아 가지 않았습니다.) 따라서 경계 값 분석은 우리에게 단지 철저한 테스트를 수행하기위한 128 개의 테스트 사례와 비교하여 완벽한 적용 범위를 보장하는 17 개의 테스트 사례. (조합론에 따르면 철저한 테스트는 실제 응용 프로그램에서는 불가능하다고 말할 수는 없습니다!)

아마 내 의견은 너무 인기가 없습니다. 그러나 단위 테스트를 통해 경제적 일 것을 제안합니다. 단위 테스트가 너무 많으면 실제 코딩이 아닌 테스트를 유지 관리하는 데 시간의 절반 이상을 쉽게 소비 할 수 있습니다.

장에 기분이 나쁘거나 매우 중요하거나 초등적인 것들에 대한 테스트를 작성하는 것이 좋습니다. IMHO 단위 테스트는 우수한 엔지니어링 및 방어 코딩을 대체하지 않습니다. 현재 나는 다소 쓸모없는 프로젝트를 진행하고 있습니다. 정말 안정적이지만 리팩토링하는 데 어려움이 있습니다. 실제로 1 년 안에 아무도이 코드를 건드리지 않았으며 그 기반이되는 소프트웨어 스택은 4 살입니다. 왜? 단위 테스트가 복잡하기 때문에 단위 테스트와 자동화 된 통합 테스트가 정확합니다. (오이 등을 들어 본 적이 있습니까?) 그리고 가장 중요한 부분은 다음과 같습니다.이 (아직) 사용 불가능한이 소프트웨어는 직원들이 테스트 중심 개발 현장에서 개척자 인 회사에 의해 개발되었습니다. :디

그래서 내 제안은 다음과 같습니다.

• 기본 스켈레톤을 개발 한 후 테스트 작성을 시작하십시오 . 그렇지 않으면 리팩토링이 어려울 수 있습니다. 다른 사람을 위해 개발하는 개발자는 처음부터 요구 사항을 절대 얻지 못합니다.

• 단위 테스트를 빠르게 수행 할 수 있는지 확인하십시오. 오이와 같은 통합 테스트가 있다면 조금 더 오래 걸리더라도 괜찮습니다. 그러나 장기 테스트는 재미가 없습니다. (사람들은 C ++이 인기를 얻지 못한 모든 이유를 잊어 버립니다 ...)

• 이 TDD를 TDD 전문가에게 맡기십시오.

• 그리고 예, 때로는 예상치 못한 부분에 따라 에지 케이스에, 때로는 일반적인 케이스에 집중하기도합니다. 항상 예상치 못한 결과를 예상하더라도 워크 플로우와 훈련을 다시 생각해야합니다. ;-)

Test Driven Development로 먼저 테스트하는 경우, 실패한 단위 테스트를 먼저 작성하지 않고 기능을 추가하지 않기 때문에 적용 범위가 90 % 이상이 될 것입니다.

사실 후에 테스트를 추가하는 경우 Michael Feathers의 레거시 코드 로 효과적으로 작업하기 사본을 얻고 코드 에 테스트를 추가하는 방법과 코드를 리팩터링하는 방법을 살펴볼 수는 없습니다. 더 테스트 가능하게 만들기 위해.

테스트 주도 개발 관행을 따르기 시작 하면 프로세스를 안내 하고 테스트 대상을 자연스럽게 알 수 있습니다. 시작해야 할 곳 :

테스트 우선

절대로 테스트를 작성하기 전에 코드를 작성하지 마십시오. 자세한 내용은 빨강 녹색 리 팩터 반복 을 참조하십시오 .

회귀 테스트 작성

버그가 발생할 때마다 테스트 케이스를 작성하고 실패 했는지 확인하십시오 . 실패한 테스트 케이스를 통해 버그를 재현 할 수 없다면 실제로 찾지 못했습니다.

적녹 리 팩터-반복

빨간색 : 구현하려는 동작에 대한 가장 기본적인 테스트를 작성하여 시작하십시오. 작업중인 클래스 또는 함수를 사용하는 예제 코드를 작성할 때이 단계를 생각하십시오. 컴파일 / 구문 오류가없고 실패 하는지 확인하십시오 . 이것은 분명해야합니다. 코드를 작성하지 않았으므로 실패해야합니까? 여기서 배워야 할 중요한 점은 테스트가 한 번 이상 실패하는 것을 보지 않는 한 테스트가 통과 한 경우 가짜 이유 때문에 수행 한 작업으로 인해 수행된다는 것을 절대 확신 할 수 없다는 것입니다.

녹색 : 실제로 테스트를 통과시키는 가장 단순하고 멍청한 코드를 작성하십시오. 똑똑하지 마십시오. 명백한 경우가 있지만 테스트에서 고려해야 할 사항이 있음에도 불구 하고 처리하기 위해 코드를 작성 하지 마십시오 (단, 경우를 잊지 마십시오 : 나중에 필요할 것입니다). 아이디어는 요 쓰기 모든 코드는 모든이 있다는 것입니다 if, 모든이 try: ... except: ...테스트 케이스에 의해 정당화되어야한다. 코드가 우아하거나 빠르거나 최적화 될 필요는 없습니다. 당신은 시험에 합격하기를 원합니다.

리 팩터 : 코드를 정리하고 메소드 이름을 올바르게 가져 오십시오. 테스트가 여전히 통과하고 있는지 확인하십시오. 최적화하십시오. 테스트를 다시 실행하십시오.

반복 : 테스트에서 다루지 않은 중요한 사례를 기억하십니까? 이제 큰 순간입니다. 해당 상황을 다루는 테스트 케이스를 작성하고, 실패한 것을보고, 코드를 작성하고, 전달, 리팩터링을보십시오.

테스트 당신의 코드를

특정 코드 조각을 작업 중이며 정확하게 테스트하려는 것입니다. 이것은 라이브러리 함수, 표준 라이브러리 또는 컴파일러를 테스트해서는 안됨을 의미합니다. 또한 "세계"테스트를 피하십시오. 여기에는 다음이 포함됩니다 : 외부 웹 API 호출, 일부 데이터베이스 집약적 요소 등

단위 테스트의 경우 의도 한 기능을 수행하는지 테스트로 시작하십시오. 가장 먼저 쓰는 것이 좋습니다. 디자인의 일부가 "정크를 건네면 예외를 던져야"하는 경우, 디자인의 일부이므로이를 테스트하십시오.

그것부터 시작하십시오. 가장 기본적인 테스트를 수행 한 경험이 있으면 테스트가 충분한 지 배우기 시작하고 테스트가 필요한 코드의 다른 측면을보기 시작합니다.

주된 답변은 "깨질 수있는 모든 것을 테스트하는 것" 입니다.

깨기에는 너무 간단한 것이 무엇입니까? 데이터 필드, 브레인 데드 속성 접근 자 및 유사한 상용구 오버 헤드 다른 어떤 것도 요구 사항의 식별 가능한 일부를 구현하며 테스트를 통해 이익을 얻을 수 있습니다.

물론, 마일리지와 작업 환경의 관행은 다를 수 있습니다.