mockit.VerificationsInOrder Maven / Gradle / Ivy
/*
* Copyright (c) 2006 Rogério Liesenfeld
* This file is subject to the terms of the MIT license (see LICENSE.txt).
*/
package mockit;
import mockit.internal.expectations.*;
/**
* Same as {@link Verifications}, but checking that invocations from code under test occurred in the same order as the
* verified expectations.
*
*
* // Exercise tested code.
* codeUnderTest.doSomething();
*
* // Now verify that the expected invocations occurred in a given order.
* new VerificationsInOrder() {{
* mock1.firstExpectedMethod(anyInt); minTimes = 1;
* mock2.secondExpectedMethod(1, "test"); maxTimes = 2;
* MockedClass.finalMethod(anyString);
* }};
*
*
* @see #VerificationsInOrder()
* @see #unverifiedInvocations()
* @see #verifiedInvocations(Verifications)
* @see Tutorial
*/
public abstract class VerificationsInOrder extends Verifications
{
/**
* Begins in-order verification on the mocked types/instances that were invoked while executing code under
* test.
*/
protected VerificationsInOrder() { super(true); }
/**
* Accounts for a sequence of invocations executed by code under test that are not explicitly verified in any
* verification block.
* Such a "sequence" of invocations can include only a single invocation, or even be empty.
*
* Invocations matching an expectation recorded with a minimum invocation count - if any - are also
* included here, since their replay order could not be verified otherwise.
* This doesn't apply to strict expectations, though, since in that case the replay order must be as
* recorded.
*
* This method can be used to verify that one or more consecutive invocations occurred before others, and
* conversely to verify that one or more consecutive invocations occurred after others.
* The call to this method marks the position where the unverified invocations are expected to have occurred,
* relative to the explicitly verified ones.
*
* The exact sequence of unverified invocations accounted for by a particular call to this method depends on the
* position of the call relative to other verifications.
* Each grouping of explicit verifications will correspond to a sequence of consecutive (and verified)
* invocations from the code under test.
* So, if this method is called more than once from the same verification block, each call will account for a
* separate sequence of unverified invocations; each sequence will be verified to occur, as a whole, in the same
* order as it appears relative to those groupings of verified invocations.
*
* Notice that when this method is not used, the invocations from code under test need not be consecutive,
* but only have the same relative order as the verification calls.
*
* Finally, notice that you can combine an ordered verification block that verifies the position of some calls
* relative to others with a later unordered block which verifies some or all of those other invocations.
* The unordered block should not come before, however, since it would "consume" the verified invocations.
*
* @see #verifiedInvocations(Verifications)
* @see Tutorial
*/
protected final void unverifiedInvocations()
{
((OrderedVerificationPhase) verificationPhase).fixPositionOfUnverifiedExpectations();
}
/**
* Accounts for a sequence of invocations executed from code under test that have already been explicitly verified in
* a previous verification block.
*
* @param alreadyVerified an unordered verification block describing a group of already verified invocations
*
* @throws IllegalArgumentException if the given verifications are ordered
*
* @see #unverifiedInvocations()
* @see Tutorial
*/
protected final void verifiedInvocations(Verifications alreadyVerified)
{
((OrderedVerificationPhase) verificationPhase).checkOrderOfVerifiedInvocations(
alreadyVerified.verificationPhase);
}
}