mockit.VerificationsInOrder Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of jmockit Show documentation
Show all versions of jmockit Show documentation
JMockit is a Java toolkit for developer (unit/integration) testing.
It contains mocking APIs and other tools, supporting both JUnit and TestNG.
The mocking APIs allow all kinds of Java code, without testability restrictions, to be tested
in isolation from selected dependencies.
/*
* Copyright (c) 2006-2011 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 in the replay phase occurred in the same order as
* specified in this ordered verification block.
*
* In the
* Tutorial
*
* @see #VerificationsInOrder()
* @see #VerificationsInOrder(int)
* @see #unverifiedInvocations()
* @see #verifiedInvocations(Verifications)
*/
public abstract class VerificationsInOrder extends Verifications
{
/**
* Begins in-order verification on the mocked types/instances invoked during the replay phase of the test.
*/
protected VerificationsInOrder()
{
super(true);
}
/**
* Begins in-order verification on the mocked types/instances invoked during the replay phase of the test.
*
* The effect of specifying a number of iterations larger than 1 (one) is equivalent to duplicating (like in "copy &
* paste") the whole sequence of invocations in the block.
*
* @param numberOfIterations the positive number of iterations for the whole set of invocations
* verified inside the block; when not specified, 1 (one) iteration is assumed
*/
protected VerificationsInOrder(int numberOfIterations)
{
super(true);
verificationPhase.setNumberOfIterations(numberOfIterations);
}
/**
* Accounts for a sequence of non-strict invocations executed in the replay phase that are not explicitly verified
* in this block or in a previous 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 the explicit verifications in the block.
* Each grouping of explicit verifications in the block will correspond to a sequence of consecutive
* (and verified) invocations in the replay phase of the 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 in the replay phase need not be consecutive,
* but only have the same relative order as the verification calls.
*
* Finally, notice that you can combine an ordered 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 In
* the Tutorial
*/
protected final void unverifiedInvocations()
{
((OrderedVerificationPhase) verificationPhase).fixPositionOfUnverifiedExpectations();
}
/**
* Accounts for a sequence of non-strict invocations executed in the replay phase 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 In
* the Tutorial
*/
protected final void verifiedInvocations(Verifications alreadyVerified)
{
((OrderedVerificationPhase) verificationPhase).checkOrderOfVerifiedInvocations(
alreadyVerified.verificationPhase);
}
}