단위 테스트와 통합 테스트 사이의 선을 어디에서 그려야합니까? 그들은 분리해야합니까?

내가 작업 한 작은 MVC 프레임 워크가 있습니다. 코드베이스는 확실히 크지 않지만 더 이상 두 클래스가 아닙니다. 나는 마침내 뛰어 들기로 결정하고 테스트를 작성하기로 결정했습니다 (예, 내가 함께해야한다고 알고 있지만 API는 지금까지 매우 불안정했습니다)

어쨌든 내 계획은 통합 테스트를 포함하여 테스트를 매우 쉽게하는 것입니다. 통합 테스트의 예는 다음과 같이 진행됩니다.

가짜 HTTP 요청 개체-> MVC 프레임 워크-> HTTP 응답 개체-> 응답이 올바른지 확인

이것은 상태 또는 특수 도구 (브라우저 자동화 등)없이 모두 가능하므로 정기적 인 단위 테스트 프레임 워크 (NUnit 사용)를 사용하면 실제로이 작업을 쉽게 수행 할 수 있습니다.

이제 큰 질문입니다. 단위 테스트와 통합 테스트 사이의 선을 정확히 어디에 그려야합니까? 단위 테스트를 사용하여 한 번에 한 클래스 만 (가능한 한 많이) 테스트해야합니까? 또한 통합 테스트를 단위 테스트 프로젝트와 동일한 테스트 프로젝트에 배치해야합니까?

통합 대 단위 테스트

단위 테스트와 통합 테스트는 완전히 분리되어 있어야합니다. 단위 테스트는 한 가지만 테스트하고 나머지 시스템은 완전히 격리해야합니다. 단위는 느슨하게 정의되어 있지만 일반적으로 방법이나 함수로 귀결됩니다.

각 장치에 대해 테스트를 수행하여 알고리즘이 올바르게 구현되었음을 알 수 있으며 구현에 결함이있는 경우 무엇이 잘못되었는지 즉시 알 수 있습니다.

단위 테스트 중에 완전한 격리 테스트를 수행하므로 스텁 및 모의 객체 를 사용 하여 나머지 응용 프로그램처럼 작동합니다. 여기에서 통합 테스트가 시작됩니다. 모든 장치를 개별적으로 테스트하는 것은 좋지만 실제로 장치가 함께 작동하는지 알아야합니다.

이는 모델이 실제로 데이터베이스에 저장되어 있는지 또는 알고리즘 X가 실패한 후 실제로 경고가 발행되는지 아는 것을 의미합니다.

테스트 주도 개발

한 걸음 물러서서 TDD (Test Driven Development)를 살펴보면 몇 가지 고려해야 할 사항이 있습니다.

1. 실제로 통과시키는 코드를 작성하기 전에 단위 테스트를 작성하십시오.
2. 테스트를 통과하고이를 달성하기에 충분한 코드 만 작성하십시오.
3. 이제 테스트가 통과되었으므로 한 걸음 물러서야합니다. 이 새로운 기능으로 리팩터링해야 할 것이 있습니까? 모든 것이 테스트에 포함되므로 안전하게 수행 할 수 있습니다.

통합 우선과 마지막 통합

통합 테스트는 두 가지 방법 중 하나로이 TDD주기에 적합합니다. 미리 글을 쓰는 사람들을 알고 있습니다. 통합 테스트를 엔드-투-엔드 (end-to-end) 테스트라고하며, 유스 케이스의 전체 경로 (애플리케이션 설정, 부트 스트래핑, 컨트롤러로 이동, 실행, 결과 확인, 출력 등 ...). 그런 다음 첫 번째 단위 테스트부터 시작하여 통과, 두 번째 추가, 통과 등을 수행합니다. 기능이 완료 될 때까지 점점 더 많은 통합 테스트 부분이 통과합니다.

다른 스타일은 단위 테스트로 피쳐 단위 테스트를 작성하고 나중에 필요한 것으로 간주되는 통합 테스트를 추가하는 것입니다. 이 두 가지의 큰 차이점은 통합 테스트의 경우 먼저 응용 프로그램의 디자인을 생각해야한다는 것입니다. 이런 종류의 TDD는 TDD가 응용 프로그램 설계에 관한 것이지 테스트에 관한 것이라는 전제에 동의하지 않습니다.

실용성

우리는 같은 프로젝트에서 모든 테스트를 수행합니다. 그러나 다른 그룹이 있습니다. 연속 통합 도구는 먼저 단위 테스트로 표시된 것을 실행합니다. 성공한 경우에만 (실제 요청, 실제 데이터베이스 사용 등) 통합 테스트 실행이 느려집니다.

우리는 보통 한 클래스에 하나의 테스트 파일을 사용합니다.

추천 독서

1. 테스트에 따라 성장하는 객체 지향 소프트웨어이 책은 통합 테스트 첫 번째 방법론의 매우 좋은 예입니다
2. dot.net의 예제를 사용한 단위 테스트 기술 dot.net의 예제를 사용한 단위 테스트 : D 단위 테스트의 기본 원리에 대한 훌륭한 책
3. TDD에 관한 Robert C. Martin (무료 기사) : 그가 링크 한 첫 두 기사도 읽어보십시오.

모든 테스트 전략에서 중요한 것은 Test Coverage입니다. 즉, 모든 기능이 테스트되고 있음을 보여줄 수 있습니다.

일반적으로, 상황에 맞지 않는 반대되는 특정 요구 사항 (예 : DO178 레벨 A, IEC61508 SIL 4 등)이 없다면 클래스 또는 모듈의 전체 기능을 테스트 할 수있는 경우 시스템 수준에서 시스템 수준 테스트를 수행 한 것으로 입증하십시오. 그리고 아래로. 단위 테스트는 더 이상 테스트를 다루지 않은 경우에만 필요합니다.

단위 테스트와 통합 테스트 사이의 선을 정확히 어디에 그려야합니까?

통합 테스트가 일반적으로 더 쉽고 빠르며 저렴하다는 것을 감안할 때 가능한 한 멀리 선을 그립니다.

단위 테스트를 사용하여 한 번에 한 클래스 만 (가능한 한 많이) 테스트해야합니까?

그것은 범위에 달려 있습니다. 다시 정의하자면 단위 테스트는 단일 단위를 테스트하고 있습니다. 그러나 전체 모듈을 한 번에 완전히 테스트 할 수 있다면 원하는 경우 그렇게하십시오. 한 번의 타격으로 여러 단위 테스트를 수행 할 수 있습니다.

또한 통합 테스트를 단위 테스트 프로젝트와 동일한 테스트 프로젝트에 배치해야합니까?

독립적 인 테스터가 더 높은 수준의 테스트를 수행하지 않는 한, 실행 가능한 최소한의 계측 만 수행해야하는 기본 이유는 없습니다.

작은 프로젝트가있을 때 모든 테스트를 동일한 프로젝트에 넣습니다. 더 큰 프로젝트는 이러한 분할을 가지기 때문에 필요할 때 분리 할 수 ​​있습니다.

단위 테스트를 사용하면 일반적으로 파일에서 하나의 클래스 (SUT) 만 테스트합니다.