단위 테스트는 '기능적'소프트웨어 만 포함해야합니다

우리는 새로운 소프트웨어 개발 프로젝트에서 StructureMap 을 사용하고 있습니다. 팀 구성원 중 하나가 기본적으로 StructureMap 컨테이너 구성을 테스트하는 단위 테스트를 구현했습니다 . 다음을 수행하여이를 수행합니다.

• 응용 프로그램 네임 스페이스의 클래스에 대해 구성된 어셈블리 인스턴스 수를 계산합니다.
• 클래스 수준에서 예상 인스턴스를 정의합니다
• 예상 인스턴스가 발견 된 총 인스턴스와 일치하는지 확인합니다.
• 예상 인스턴스가 테스트에 정의 된 인스턴스와 일치하는지 확인

이에 대한 예는 다음과 같습니다.

var repositories = container.GetAllInstances<IEnvironmentRepository>();
Assert.AreEqual(1, repositories .Count());
foundInstances = foundInstances + repositories .Count();

우리는 또한 다음 수업에 대한 '단위 테스트'를 가지고 있습니다.

public MyClass(IEnvironmentRepository environmentRepository)
        {

        }

이 테스트에서는 IEnvironmentRepository를 모방하므로 라이브 시스템에서와 같이 컨테이너에서 컨테이너를 주입하지 않습니다.

동료는 "단위 테스트는 자체 구성 만 테스트합니다"라는 줄에 주석이있는 구조 맵 구성의 단위 테스트를 무시했습니다. 이것은 분명히 테스트의 목적이며 내 의견으로는 완벽하게 유효합니다. 테스트를 무시한 사람이 IEnvironmentRepository(테스트는 여전히 무시한 상태)에 대한 구조 맵 구성을 제거 하고 전체 단위 테스트 스위트를 실행하도록 요청했으며 모두 통과했습니다. 그런 다음 응용 프로그램을 실행했으며 이제 컨테이너 구성이 유효하지 않기 때문에 실패했습니다. 내 의견으로는, 이것은 시험의 가치를 입증했으며 내 동료는 여전히 동의하지 않았다. 그는 우리가 구성을 테스트해서는 안된다고 말했지만, 이것이 단위 테스트의 범위 내에 있다고 생각합니다.

그래서 많은 질문들;

• 유효한 단위 테스트입니까-우리는 컨테이너 맵의 구성이 아닌 컨테이너의 구성을 테스트하고 있습니다 (그러나 중복을 볼 수는 있습니다)
• 그렇지 않은 경우 테스트하지 않고 구성을 어떻게 검증 할 수 있습니까? 실수로 필요한 코드 줄을 삭제하고 체크인하는 것을 어떻게 막을 수 있습니까?
• 해야 MyClass단위 테스트의 인스턴스를 해결 IEnvironmentRepository용기로부터이 통과?

이것은 완벽하게 유효한 자동화 테스트입니다. 코드베이스의 스켈 레탈 컴포넌트의 건전성을 검증 할 때이를 "아키텍처 테스트"라고합니다.

IoC 컨테이너가 애플리케이션의 모든 객체 트리를 분석하고 구성 할 수 있습니까? 자동 매퍼가 등록 된 모든 객체간에 실패없이 매핑 할 수 있습니까? 어니언 아키텍처의 중앙 레이어는 외부를 참조 하지 않습니까?

이 테스트를 통해 정확한 범인을 지적함으로써 구성 버그가 몰래 들어 오면 많은 시간을 절약 할 수 있습니다. 좋은 프레임 워크는 무엇이 잘못되었는지에 대한 매우 정확한 오류 메시지를 제공하며 운이 좋으면 런타임 스택 추적에 깊이 묻히지 않고 테스트를 실행하는 즉시 (이상적으로 지속적으로) 얻을 수 있습니다.

그것들이 단위 테스트인지 아닌지는 모르지만 여전히 대부분 메모리에서 작동하고 꽤 빠르게 실행됩니다. 다시 말하지만, 나는 단위 테스트에 대해 보편적으로 받아 들여진 정의와 같지 않습니다.

이와 같은 테스트의 문제점은 프로그램의 요구 사항이 아니라 프로그램의 내부를 테스트합니다. 프로그램이 필요에 따라 작동하더라도 테스트가 실패 할 수 있습니까?

귀하의 경우 컨테이너 설정을 변경할 때마다 주입이 필요한 새로운 종속성이있을 때 테스트를 중단합니다.

또한 추가 종속성 요구 사항을 추가하지만 컨테이너에 추가하고 컨테이너 테스트를 변경하는 것을 잊지 마십시오. 모든 것이 통과되지만 프로그램이 중단됩니다.

더 나은 자동화 테스트는 프로그램을 시작하고 충돌하는지 확인하는 것입니다.

단위 테스트를 통과하더라도 통합 또는 UI 테스트에서 이러한 유형의 오류를 포착해야합니다.

그러나 컨테이너 설정의 복잡성이 증가하는 것은 어려운 일입니다. 아마도 일부 '나쁜'테스트는 그만한 가치가 있습니다.

단위 테스트 테스트 코드. 이 이외의 것은 "기타"자동화 테스트입니다. 원하는대로 호출하십시오. 여기서 구성을 테스트하는 것 같습니다. 환경에 따라 구성이 변경 될 수 있으면 단위 테스트에 속하지 않습니다. 테스트가 다른 테스트와 다른 유형임을 나타내려면 테스트 속성을 추가하십시오.

의존성 주입 컨테이너의 책임은 하나의 작업 애플리케이션에서 다른 모듈을 접착하는 것 입니다.

응용 프로그램에 대해 자동화 된 테스트를 작성하는 경우 "끝에서 끝까지"테스트를 실행하는 "통합 (또는 수락)"테스트가 거의 없어야합니다.이 테스트는 응용 프로그램의 전체 파이프 라인을 테스트하여 특정 테스트 사례에 관련된 모든 모듈이 서로 붙어 있습니다. 올바르게 .

따라서 종속성 주입 컨테이너가 올바르게 구성되지 않은 경우 이러한 통합 테스트가 실패합니다. 통합 테스트는 컨테이너 구성에서 가능한 오류를 나타 내기 때문에 컨테이너 자체에 대한 단위 테스트를 쓸모 없게 만듭니다.

통합 테스트에서 가능한 모든 테스트 사례를 다룰 필요는 없습니다. UI에서 데이터베이스에 이르는 전체 기능을 다루는 기능 당 하나의 테스트 사례 만 있습니다.

통합 테스트 사례가 특정 종속성의 인스턴스화를 다루지 않는 경우 간단히 추가합니다.

통합 테스트를 통해 구성에 대한 단위 테스트를 다시 작성하지 않고도 컨테이너를 자유롭게 변경할 수 있습니다.

IMO의 답은 다음과 같습니다.

1. 유효한 단위 테스트입니까-우리는 컨테이너 맵의 구성이 아닌 컨테이너의 구성을 테스트하고 있습니다 (그러나 중복을 볼 수는 있습니다)

   • 단일 테스트는 특정 코드를 테스트하고 구현 된 로직을 테스트하기 위해 필요한 경우 모든 종속성을 조롱하기 때문에 프로젝트가 아닌 structuremap 에 대한 유효한 단위 테스트입니다 . 구성 로직은 구조 맵 내에서 구현 되므로이 라이브러리 는 잘 테스트 해야 하며 언급 한 것과 같은 단위 테스트 를 포함해야합니다 . 더 많은 : 이와 같은 수백 가지 테스트가 포함되어 런타임에 여러 구성을 동적으로 조롱하고 테스트해야합니다. 컨테이너는 정상적으로 동작합니다.

2. 그렇지 않은 경우 테스트하지 않고 구성을 어떻게 검증 할 수 있습니까? 실수로 필요한 코드 줄을 삭제하고 체크인하는 것을 어떻게 막을 수 있습니까?

   • 필요한 환경에서 구성을 수동으로 테스트 할 수 있으며, 필요한 특정 구성을 테스트하는 자동화 (자동 테스트)를 만들 수도 있습니다 (런타임시 작업을 조롱 할 필요 없음).

3. MyClass 단위 테스트가 컨테이너에서 IEnvironmentRepository 인스턴스를 확인하고이를 전달해야합니까?

   • 아니요, 의존성을 모의하고 MyClass 논리를 격리 된 방식으로 테스트하기 때문에 이것은 완벽한 단위 테스트입니다.

UnitTest 는 분리 된 유닛의 원하는 동작 을 확인 합니다 .

이것은 모든 종류의 구성 이 UnitTests 의 범위에 있지 않다는 것을 의미합니다 .

그럼에도 불구하고 구성에 대한 자동 테스트가 있어야하지만 UnitTests 는 아닙니다 ...