Проверка частично упорядоченных вызовов методов в JMockit

если вам действительно нужен такой тест, то: не используйте библиотеку для насмешек, а создайте свой собственный макет с состоянием внутри, который может просто проверить правильный порядок методов. но проверка порядка вызовов обычно является плохим признаком. мой совет: не проверяйте это, рефакторинг. вы должны проверить свою логику и результаты, а не последовательность вызовов. проверьте правильность побочных эффектов (содержимое базы данных, взаимодействие со службами и т. д.). если вы тестируете последовательность, то ваш тест в основном является точной копией вашего производственного кода. так какова добавленная стоимость такого теста? и такой тест еще и очень хрупок (как любое дублирование).

возможно, вы должны сделать свой код таким:

beginTransaction()
doTransactionalStuff()
endTransaction()
doNonTransactionalStuff()

Исходя из моего использования jmockit, я считаю, что ответ — нет даже в последней версии 1.49.

Вы можете реализовать этот тип расширенной проверки, используя расширение MockUp с некоторыми внутренними полями, чтобы отслеживать, какие функции вызываются, когда и в каком порядке.

Например, я реализовал простой MockUp для отслеживания количества вызовов методов. Цель этого примера реальна, поскольку поля Verifications и Expectations times не работали при имитации ThreadGroup (полезно и для других чувствительных типов):

public class CalledCheckMockUp<T> extends MockUp<T>
{
    private Map<String, Boolean> calledMap = Maps.newHashMap();
    private Map<String, AtomicInteger> calledCountMap = Maps.newHashMap();
    
    public void markAsCalled(String methodCalled)
    {
        if (methodCalled == null)
        {
            Log.logWarning("Caller attempted to mark a method string" +
                           " that is null as called, this is surely" +
                           " either a logic error or an unhandled edge" +
                           " case.");
        }
        else
        {
            calledMap.put(methodCalled, Boolean.TRUE);
            calledCountMap.putIfAbsent(methodCalled, new AtomicInteger()).
                incrementAndGet();
        }
    }

    public int methodCallCount(String method)
    {
        return calledCountMap.putIfAbsent(method, new AtomicInteger()).get();
    }
    
    public boolean wasMethodCalled(String method)
    {
        if (method == null)
        {
            Log.logWarning("Caller attempted to mark a method string" +
                           " that is null as called, this is surely" +
                           " either a logic error or an unhandled edge" +
                           " case.");
            return false;
        }

        return calledMap.containsKey(method) ? calledMap.get(method) :
            Boolean.FALSE;
    }
}

С использованием, как показано ниже, где cut1 — это тип динамического прокси, который обертывает фактический ThreadGroup:

String methodId = "activeCount";

CalledCheckMockUp<ThreadGroup> calledChecker = new CalledCheckMockUp<ThreadGroup>()
    {
        @Mock
        public int activeCount()
        {
            markAsCalled(methodId);
            return active;
        }
    };

. . .

int callCount = 0;
int activeCount = cut1.activeCount();
callCount += 1;

Assertions.assertTrue(calledChecker.wasMethodCalled(methodId));
Assertions.assertEquals(callCount, calledChecker.methodCallCount(methodId));

Я знаю, что вопрос старый, и этот пример не совсем соответствует варианту использования OP, но надеюсь, что он может помочь другим найти потенциальное решение, которое они ищут (или OP, не дай Бог, это все еще не решено для важного варианта использования, который вряд ли).

Учитывая сложность того, что пытается сделать OP, может помочь переопределить метод $advice в вашем пользовательском MockUp, чтобы упростить дифференцирование и запись вызовов методов. Документы здесь: Применение рекомендаций в стиле АОП.