2010-11-28 2 views
5

IoC 컨테이너 인 Autofac을 사용하기 위해 복잡한 생성 코드를 변환하려고합니다. TDD를 아주 잘 믿고 있기 때문에 Module 구성에 대한 단위 테스트를 작성하고 있습니다.명명 된 구성 요소를 사용하여이 IoC 등록을 단위 테스트하는 방법? (Autofac)

기능의 대부분은 매우 쉽게 테스트 할 수 있습니다.

var obj = container.Resolve<IThing>(); 
Assert.IsInstanceOfType(obj, typeof(ThingImplementer)); 

하지만 동일한 인터페이스의 구현자가 여러 개 있고 구현자가 다른 구체적인 클래스로 전달되는 경우가 많습니다. 예 : 이름이 지정된 등록을 사용하여이를 해결했습니다. 내가 알아낼 수 없습니다 무엇

builder.RegisterType<ThingImplementer>().Named<IThing>("Implementer1"); 
builder.RegisterType<OtherImplementer>().Named<IThing>("Implementer2"); 
builder.Register(c => new Foo(c.ResolveNamed<IThing>("Implementer1"))).As<IFoo>(); 

는 푸 ThingImplementer하지 OtherImplementer를 얻을 수 있음을 보장하는 단위 테스트를 작성하는 쉬운 방법입니다. 노력해야 할 가치가 있는지 궁금해합니다. 우리는이를 포괄하는 높은 수준의 통합 테스트를 수행하고 있지만, 단위 테스트에서 수행하는 문서화 또는 리팩토링 이점을 제공하지는 않습니다.

단위 테스트를 작성 하시겠습니까? 그렇다면 어떻게?

답변

7

일반적으로 단위 테스트에서 컨테이너 구성을 테스트하지 않습니다. 단위 테스트 환경에서는 컨테이너를 사용하여 종속성을 주입하지 않습니다 (수동으로 수행). 이렇게하면 실제/프로덕션 유형이 아닌 위조 된 객체를 주입하게됩니다. 따라서 컨테이너 구성은 일반적으로 단위 테스트에서 알 수 없습니다.

때때로 나는 컨테이너가 응용 프로그램의 루트 유형 (예 : MVC 응용 프로그램의 컨트롤러 클래스 또는 WebForms 응용 프로그램의 페이지 클래스)을 만들 수 있는지 테스트합니다. 컨테이너는 객체 그래프를 인스턴스화하기 때문에 컨테이너가 올바르게 구성되었는지 여부를 알 수 있습니다. 그러나 컨테이너가 올바른 구현을 반환하면 나는 결코 관심이 없다. 대부분의 경우 응용 프로그램 루트에서 액세스 할 수있는 등록 된 인터페이스가 하나만 구현되어있어 잘못 될 가능성이 거의 없습니다.

컨테이너 구성을 테스트하려면 너무 복잡하기 때문에 등록을 단순화 할 수 있도록 응용 프로그램 디자인을 단순화해야합니다.

2

여기에 새로운 내용이 없으며 Steven의 포인트가 확장되었습니다.

스티븐이 말했듯이, 그건 분명히 단위 테스트가 아닙니다. 당신은 아마도 그것을 학습 테스트로 볼 수 있습니다. Ninject 테스트 슈트를 살펴보십시오 - 테스트가 어떻게 수행되는지를 보여줍니다 (하지만 컨테이너를 작성하고 있음을 기억하십시오). 나는 autofac이 비슷한 테스트를한다고 가정합니다.

재미있는 행동이 있다고 느껴지고 눈에 띄지 않게 될 경우 통합 스위트에 끼우는 것이 위험하지 않습니다.

외부의 사실에 관한 또 다른 요지는 매우 유효합니다. Onion Architecture

의 개념을 참조하십시오.
관련 문제