체인 콜의 모의 또는 스터브

체인 콜의 모의 또는 스터브

protected int parseExpire(CacheContext ctx) throws AttributeDefineException {
    Method targetMethod = ctx.getTargetMethod();
    CacheEnable cacheEnable = targetMethod.getAnnotation(CacheEnable.class);
    ExpireExpr cacheExpire = targetMethod.getAnnotation(ExpireExpr.class);
    // check for duplicate setting
    if (cacheEnable.expire() != CacheAttribute.DO_NOT_EXPIRE && cacheExpire != null) {
        throw new AttributeDefineException("expire are defined both in @CacheEnable and @ExpireExpr");
    }
    // expire time defined in @CacheEnable or @ExpireExpr
    return cacheEnable.expire() != CacheAttribute.DO_NOT_EXPIRE ? cacheEnable.expire() : parseExpireExpr(cacheExpire, ctx.getArgument());
}

이것이 테스트하는 방법입니다.

Method targetMethod = ctx.getTargetMethod();
CacheEnable cacheEnable = targetMethod.getAnnotation(CacheEnable.class);

3개의 Cache Context, Method 및 Cache Enable을 시뮬레이션해야 합니다.테스트 케이스를 좀 더 간단하게 할 수 있는 방법이 없을까요?

Mockito는 체인 스터브를 처리할 수 있습니다.

Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);

// note that we're stubbing a chain of methods here: getBar().getName()
when(mock.getBar().getName()).thenReturn("deep");

// note that we're chaining method calls: getBar().getName()
assertEquals("deep", mock.getBar().getName());

체인의 첫 번째 메서드는 두 번째 체인 메서드콜에서 값을 반환하도록 설정된 모크를 반환합니다.

Mockito의 저자들은 이것이 레거시 코드에만 사용되어야 한다고 지적한다.그렇지 않으면 동작을 CacheContext에 푸시하여 작업 자체에 필요한 정보를 제공하는 것이 좋습니다.Cache Context에서 추출한 정보의 양은 클래스에 기능 선망의 대상이 되고 있음을 나타냅니다.

혹시 Kotlin을 사용할까 봐.MockK는 체인이 나쁜 관행이라고 말하지 않고 쉽게 허락합니다.

val car = mockk<Car>()

every { car.door(DoorType.FRONT_LEFT).windowState() } returns WindowState.UP

car.door(DoorType.FRONT_LEFT) // returns chained mock for Door
car.door(DoorType.FRONT_LEFT).windowState() // returns WindowState.UP

verify { car.door(DoorType.FRONT_LEFT).windowState() }

confirmVerified(car)

당신의 테스트 케이스를 간단하게 하기 위해 제안하고 싶은 것은 당신의 방법을 재팩터화하는 것입니다.

방법을 테스트하는 데 어려움을 겪을 때마다 코드 냄새에 시달리고, 왜 테스트가 어려운지 묻습니다.또한 코드를 테스트하기 어렵다면 사용 및 유지보수가 어려울 수 있습니다.

이 경우 여러 레벨의 메서드 체인이 있기 때문입니다.파라미터로 ctx, cacheEnable 및 cacheExpire를 전달합니다.

JMockit은 사용하기 쉽고 완전히 바뀌었습니다.테스트 케이스를 참조해 주세요.

https://github.com/ko5tik/andject/blob/master/src/test/java/de/pribluda/android/andject/ViewInjectionTest.java

여기에서는 Android SKD에서 온 완전히 stubded인 Activity base 클래스를 조롱합니다.JMockit을 사용하면 최종, 비공개, 추상 또는 기타 모든 것을 조롱할 수 있습니다.

테스트 케이스에서는 다음과 같습니다.

public void testFoo(@Mocked final Method targetMethod, 
                    @Mocked  final CacheContext context,
                    @Mocked final  CacheExpire ce) {
    new Expectations() {
       {
           // specify expected sequence of infocations here

           context.getTargetMethod(); returns(method);
       }
    };

    // call your method
    assertSomething(objectUndertest.cacheExpire(context))

Lunivore의 답변에 대해 자세히 설명하자면, 조롱된 콩을 주입하는 사람은 다음을 사용하십시오.

@Mock(answer=RETURNS_DEEP_STUBS)
private Foo mockedFoo;

언급URL : https://stackoverflow.com/questions/7926891/mock-or-stub-for-chained-call