단위 테스트 방법 매개 변수 확인 모범 사례

Question

단위 테스트시 복잡한 매개 변수를 사용하여 메서드 호출을 확인하는 가장 좋은 방법은 무엇입니까? 검증 않는

A) :

class ClassA { 
    ClassB dependency; 

    void someFunction(SomeInputForA input) { 
    // do some thing 
    dependency.anotherFunction(differentInput); 
    } 
} 

내가 someFunction 전화 적절한 입력을 anotherFunction이라는 것을 검증 생각할 수있는 두 가지 옵션 :

내가이 같은 기능을 시험하고있어 말 anotherFunction

unitUnderTest.dependency = mockClassB; 

InputClass expectedDifferentInput = ... ; 

verify(mockClassB).anotherFunction(expectedDifferentInput); 

B)를 호출에 대한 의존성의 모의에 anotherFunction와 t을 주장의 호출에 인수 납치범을 그는 속성

unitUnderTest.dependency = mockClassB; 

ArgumentCaptor<InputClass> captor = ArgumentCaptor.for(InputClass.class); 

verify(mockClassB).anotherFunction(captor.capture()); 

InputClass capturedInput = captor.getValue(); 
assertEquals(value, capturedInput.param1); 
// and more asserts afterwards 

여기에 제안 된 경로가 있습니까? 더 엄격한 느낌이 들기 때문에 객체가 올바른 구현체와 동일하지 않기 때문에 캡처 메소드쪽으로 기울여야합니다.

생각?

Answer 1

다른 입력이 입력에서 계산되지 않습니까?

Input A에 대해 말하는 것처럼 B)를 사용하는 것이 더 나을 경우 ClassA에서 expectedDifferentInput으로 변경하고 위임 클래스 (ClassB)가 호출되는지 확인하려고합니다. ClassA의 입력 및 위임 논리의 변형을 검증합니다.

differentInput이 입력과 관련이없는 경우 캡처 도구를 사용하지 않아도 실제로 위임을 확인하는 중일뿐입니다.

ClassA의 someFunction에 대한 모든 public 발신자는 ClassB에 대해 알 필요가 없으므로 A) 및 B) 두 방법 모두 실제로는 white box testing이라고 할 수 있으므로 어쨌든 사용하는 것이 좋습니다. someFunction에 대한 입력을 다양하게 할 때, capther는 differentInput이 입력에서 계산되지 않으면 엣지 케이스를 식별하도록 도울 수 있습니다.

Answer 2

mockClassB.anotherFunction()에 전달 된 객체에서 항상 matchers를 사용할 수 있습니다. 당신이 객체에 필드를 비교하려는 경우 예를 들어, 당신은 쓸 수 있습니다 :

Matcher<YourClass> yourMatcher = Matchers.hasProperty("yourProperty", Matchers.equals(whatever)); 
verify(mockClassB).anotherFunction(argThat(yourMatcher)); 

를 당신이 구문을 공유 할 때와 상기 정합 기 위해 확인하고의 조합을 결합 할 수 있기 때문에 나는이 방법을 선호 matchers. 이 기능을 사용하려면 최신 mockito 및 hamcrest 라이브러리가 필요합니다.

Answer 3

나는 인수 인수를 사용했지만 매우 조심스럽게 사용했습니다. 가장 큰 문제는이 경로가 부서지기 쉬운 단위 테스트를 생성한다는 것입니다. 클래스에 작은 변화를 주었을 때 아무도 행복하지 않아서 영향을 받아서는 안되는 클래스를 호출 할 때 단위 테스트로 어려움을 겪습니다.

그렇다면 결국 올바른 호출이 이루어 지도록해야합니다. 그러나 equals override 작업에 의존한다면, equals 메서드를 사용하는 클래스에 의존하고 있으며,이 클래스의 계약 (그리고 그 클래스에서 테스트 한 유닛)은 합리적입니다.

그래서 내가 간단하게 확인하고 사용하는 것에 투표 할 것입니다. 결국 같은 일이지만, 당신의 단위 테스트는 그다지 허약하지 않습니다.