макет або заглушка для ланцюгового дзвінка

Question 1

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);

Я маю знущатись із трьох CacheContext, Method та CacheEnable. Чи є ідея спростити тестовий випадок?

Question 2

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());

AFAIK, перший метод у ланцюжку повертає макет, який налаштований на повернення вашого значення при другому виклику ланцюгового методу.

Автори Mockito зазначають, що це слід використовувати лише для застарілого коду . Краще зробити інакше - ввести поведінку у свій CacheContext та надати будь-яку інформацію, необхідну для самої роботи. Кількість інформації, яку ви витягуєте з CacheContext, говорить про те, що ваш клас має заздрість до можливостей .

Question 3

Про всяк випадок, коли ви використовуєте 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)

Question 4

Моя порада спростити ваш тест - це рефакторинг вашого методу.

Щоразу, коли у мене виникають проблеми з тестуванням методу, для мене це запах коду, і я запитую, чому це важко перевірити. І якщо код важко перевірити, його, мабуть, важко використовувати та підтримувати.

У цьому випадку це тому, що у вас є ланцюжок методів, що йде на кілька рівнів углиб. Можливо, передавати в якості параметрів ctx, cacheEnable та cacheExpire.

Question 5

Я знайшов JMockit простішим у використанні і повністю перейшов на нього. Перегляньте тестові приклади з його використанням:

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

Тут я висміюю базовий клас Activity, який походить від Android SKD і повністю затуплений. За допомогою 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))