모의 객체를 바인딩하기위한 테스트 메소드 내에서 로컬로 Ninject 바인딩을 오버라이드합니다.

Question

다음과 같은 문제가 있습니다. 단위 테스트에서 Ninject를 사용하고 싶습니다. 이것에 대해 내 생각은 다음과 같다 :

1) 나는 시험 안에 사용 내 가짜 객체를 바인딩 모듈 내부에 글로벌 바인딩 스키마를 정의

2) 내부에 로컬로 바인드 모의 객체를 사용하여 테스트

바인딩 구성을 로컬에서 덮어 쓰는 방법을 찾지 못했습니다. 제 생각으로 예상치 않게 모의 개체를 만듭니다. kernel.Get() 메서드를 사용하여 모든 바인딩이있는 개체를 반환합니다. 각각의 테스트가 기대와 함께 테스트 내에서 로컬 mock 객체를 추가한다는 점을 제외하고는, 이것은 테스트 당 하나의 바인딩만을 오버라이드하기 때문에 읽기 쉽고 유지하기가 쉽습니다. ar 테스트 문맥을 알 수 없으므로 모듈 내부에서 구성 할 수 없으므로 모의 테스트를 수행합니다.

어떻게하면 C# 및 nunit을 사용할 수 있습니까? 내 방법론이 잘못된 경우 올바른 것을 듣고 싶습니다.

Answer 1

단위 테스트에서 테스트 할 개체를 만들 때 IoC 컨테이너를 사용하면 안됩니다. 대신 new을 사용하여 수동으로 생성하고 각 생성자 인수에 대한 mock/stub 객체를 전달하십시오.

Answer 2

나는 똑같은 문제가 있으며 그것이 좋은 방법이 아니라는 것을 이해한다. 그러나 내 편에서는 통합 테스트를한다. 단위 테스트가 아닙니다. 커널을 사용하면 바인딩을 만드는 데 사용되는 개체입니다

Kernel.Rebind<TypeToBind>().ToConstant(Mock.Object); 

:

여기 내 솔루션입니다. TypeToBind는 종속성을 주입하려는 유형입니다. Mock.Object는 이전에 설정 한 개체입니다.

다시 말해서별로 좋지는 않지만 유닛 테스트가 삽입하기 어려운 레거시 코드 작업을하는 동안 좋은 안전망을 가질 수있는 구원이 될 수 있습니다.

Answer 3

테스트를 위해 IoC 프레임 워크를 사용하는 것이 최선의 방법이라고 생각합니다. 사실, 이것이 바로 IoC가 처음부터 존재하고 프레임 워크가 등장한 이유입니다. Guice (google의 Java injection DI 프레임 워크)는 실제로 프로덕션 바인딩으로 모듈을 전달한 다음 특정 바인딩을 mockobjects로 대체 할 수있는 TestModule을 전달한 다음 테스트 할 수있는이 기능을 실제로 지원합니다. 우리는 이것을 해왔고 자바에서 오랜 시간 동안 매우 깨끗합니다. 나는 지금 내 테스트가 물건을 리바 인딩하려고 노력하지만 바인딩의 나머지 부분은 유지하려고 노력하고있다. ...

또한 DI 프레임 워크를 사용하여 오브젝트를 테스트해야하는 AtUnit과 같은 프레임 워크가있다 (안타깝게도 C# 토큰에 해당 프레임 워크의 포트가 아직 보이지 않습니다.().

참고 : 이는 사람들이 프로덕션 환경에서 새 바인딩을 추가 할 때 바람직한 이유입니다. 모듈을 테스트 한 다음 내 시스템의 테스트 클래스에서 사용하면 nullpointer 예외가 발생하지 않습니다. 인터페이스가 테스트에서 바인딩되지 않았기 때문에 사람들은 계속 추가하고 테스트는 계속 작동합니다. 키워드 dtos와 같은 "새로운"요즘과 모든 비즈니스 로직은 DI와 함께 유선되어야 쉽게 o 테스트를 지금 또는 나중에 추가하십시오. (물론 테스트 자체를 추가하고 싶지만).