Package mockit

Class VerificationsInOrder

java.lang.Object
mockit.Verifications
mockit.VerificationsInOrder
public class VerificationsInOrder extends Verifications
Same as Verifications, but checking that invocations from code under test occur 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() {{
    <strong>mock1</strong>.firstExpectedMethod(anyInt); minTimes = 1;
    <strong>mock2</strong>.secondExpectedMethod(1, "test"); maxTimes = 2;
    <strong>MockedClass</strong>.finalMethod(anyString);
 }};
See Also:

  • Field Summary

    Fields
    Modifier and Type
    Field
    Description
    protected final Object
    any
    Matches any Object reference received by a parameter of a reference type.
    protected final Boolean
    anyBoolean
    Matches any boolean or Boolean value received by a parameter of that type.
    protected final Byte
    anyByte
    Matches any byte or Byte value received by a parameter of that type.
    protected final Character
    anyChar
    Matches any char or Character value received by a parameter of that type.
    protected final Double
    anyDouble
    Matches any double or Double value received by a parameter of that type.
    protected final Float
    anyFloat
    Matches any float or Float value received by a parameter of that type.
    protected final Integer
    anyInt
    Matches any int or Integer value received by a parameter of that type.
    protected final Long
    anyLong
    Matches any long or Long value received by a parameter of that type.
    protected final Short
    anyShort
    Matches any short or Short value received by a parameter of that type.
    protected final String
    anyString
    Matches any String value received by a parameter of this type.
    protected int
    maxTimes
    A non-negative value assigned to this field will be taken as the maximum number of times that invocations matching the current expectation should occur during replay.
    protected int
    minTimes
    A positive value assigned to this field will be taken as the minimum number of times that invocations matching the current expectation should occur during replay.
    protected @org.checkerframework.checker.index.qual.NonNegative int
    times
    A non-negative value assigned to this field will be taken as the exact number of times that invocations matching the current expectation should occur during replay.

  • Constructor Summary

    Constructors
    Modifier
    Constructor
    Description
    protected
    VerificationsInOrder()
    Begins in-order verification on the mocked types/instances that were invoked while executing code under test.

  • Method Summary

    Modifier and Type
    Method
    Description
    protected final <T> T
    with(Delegate<? super T> objectWithDelegateMethod)
    Applies a custom argument matcher for a parameter in the current expectation.
    protected final <T> T
    withAny(T arg)
    Same as withEqual(Object), but matching any argument value of the appropriate type (null included).
    protected final <T> T
    withArgThat(org.hamcrest.Matcher<? super T> argumentMatcher)
    Applies a Hamcrest argument matcher for a parameter in the current expectation.
    protected final <T> T
    withCapture(List<T> valueHolderForMultipleInvocations)
    Captures the argument value passed into the associated expectation parameter, for each invocation that matches the expectation when the tested code is exercised.
    protected final double
    withEqual(double value, double delta)
    Same as withEqual(Object), but checking that a numeric invocation argument in the replay phase is sufficiently close to the given value.
    protected final float
    withEqual(float value, double delta)
    Same as withEqual(Object), but checking that a numeric invocation argument in the replay phase is sufficiently close to the given value.
    protected final <T> T
    withEqual(T arg)
    When passed as argument for an expectation, creates a new matcher that will check if the given value is equal to the corresponding argument received by a matching invocation.
    protected final <T> T
    withInstanceLike(T object)
    Same as withEqual(Object), but checking that an invocation argument in the replay phase is an instance of the same class as the given object.
    protected final <T> T
    withInstanceOf(Class<T> argClass)
    Same as withEqual(Object), but checking that an invocation argument in the replay phase is an instance of the given class.
    protected final <T extends CharSequence>
    T
    withMatch(T regex)
    Same as withEqual(Object), but checking that a textual invocation argument in the replay phase matches the given regular expression.
    protected final <T> T
    withNotEqual(T arg)
    Same as withEqual(Object), but checking that the invocation argument in the replay phase is different from the given value.
    protected final <T> T
    withNotNull()
    Same as withEqual(Object), but checking that an invocation argument in the replay phase is not null.
    protected final <T> T
    withNull()
    Same as withEqual(Object), but checking that an invocation argument in the replay phase is null.
    protected final <T extends CharSequence>
    T
    withPrefix(T text)
    Same as withEqual(Object), but checking that a textual invocation argument in the replay phase starts with the given text.
    protected final <T> T
    withSameInstance(T object)
    Same as withEqual(Object), but checking that an invocation argument in the replay phase is the exact same instance as the one in the recorded/verified invocation.
    protected final <T extends CharSequence>
    T
    withSubstring(T text)
    Same as withEqual(Object), but checking that a textual invocation argument in the replay phase contains the given text as a substring.
    protected final <T extends CharSequence>
    T
    withSuffix(T text)
    Same as withEqual(Object), but checking that a textual invocation argument in the replay phase ends with the given text.

    Methods inherited from class mockit.Verifications

    withCapture, withCapture

    Methods inherited from class java.lang.Object

    clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

  • Field Details

    • any

      @Nullable protected final Object any
      Matches any Object reference received by a parameter of a reference type.

      This field can only be used as the argument value at the proper parameter position in a method/constructor invocation, when recording or verifying an expectation; it cannot be used anywhere else.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Notice the use of this field will usually require a cast to the specific parameter type. However, if there is any other parameter for which an argument matching constraint is specified, passing the null reference instead will have the same effect.

      To match an entire varargs parameter of element type V (ie, all arguments in the array), cast it to the parameter type: "(V[]) any".

      See Also:

    • anyString

      @NonNull protected final String anyString
      Matches any String value received by a parameter of this type.

      This field can only be used as the argument value at the proper parameter position in a method/constructor invocation, when recording or verifying an expectation; it cannot be used anywhere else.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      See Also:

    • anyLong

      @NonNull protected final Long anyLong
      Matches any long or Long value received by a parameter of that type.

      This field can only be used as the argument value at the proper parameter position in a method/constructor invocation, when recording or verifying an expectation; it cannot be used anywhere else.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      See Also:

    • anyInt

      @NonNull protected final Integer anyInt
      Matches any int or Integer value received by a parameter of that type.

      This field can only be used as the argument value at the proper parameter position in a method/constructor invocation, when recording or verifying an expectation; it cannot be used anywhere else.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      See Also:

    • anyShort

      @NonNull protected final Short anyShort
      Matches any short or Short value received by a parameter of that type.

      This field can only be used as the argument value at the proper parameter position in a method/constructor invocation, when recording or verifying an expectation; it cannot be used anywhere else.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      See Also:

    • anyByte

      @NonNull protected final Byte anyByte
      Matches any byte or Byte value received by a parameter of that type.

      This field can only be used as the argument value at the proper parameter position in a method/constructor invocation, when recording or verifying an expectation; it cannot be used anywhere else.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      See Also:

    • anyBoolean

      @NonNull protected final Boolean anyBoolean
      Matches any boolean or Boolean value received by a parameter of that type.

      This field can only be used as the argument value at the proper parameter position in a method/constructor invocation, when recording or verifying an expectation; it cannot be used anywhere else.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      See Also:

    • anyChar

      @NonNull protected final Character anyChar
      Matches any char or Character value received by a parameter of that type.

      This field can only be used as the argument value at the proper parameter position in a method/constructor invocation, when recording or verifying an expectation; it cannot be used anywhere else.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      See Also:

    • anyDouble

      @NonNull protected final Double anyDouble
      Matches any double or Double value received by a parameter of that type.

      This field can only be used as the argument value at the proper parameter position in a method/constructor invocation, when recording or verifying an expectation; it cannot be used anywhere else.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      See Also:

    • anyFloat

      @NonNull protected final Float anyFloat
      Matches any float or Float value received by a parameter of that type.

      This field can only be used as the argument value at the proper parameter position in a method/constructor invocation, when recording or verifying an expectation; it cannot be used anywhere else.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      See Also:

    • times

      protected @org.checkerframework.checker.index.qual.NonNegative int times
      A non-negative value assigned to this field will be taken as the exact number of times that invocations matching the current expectation should occur during replay.
      See Also:

    • minTimes

      protected int minTimes
      A positive value assigned to this field will be taken as the minimum number of times that invocations matching the current expectation should occur during replay. Zero or a negative value means there is no lower limit.

      If not specified, the default value of 1 (one) is used.

      The maximum number of times is automatically adjusted to allow any number of invocations. Both minTimes and maxTimes can be specified for the same expectation, provided minTimes is assigned first.

      See Also:

    • maxTimes

      protected int maxTimes
      A non-negative value assigned to this field will be taken as the maximum number of times that invocations matching the current expectation should occur during replay. A negative value implies there is no upper limit (the default).

      Both minTimes and maxTimes can be specified for the same expectation, provided minTimes is assigned first.

      See Also:

  • Constructor Details

    • VerificationsInOrder

      protected VerificationsInOrder()
      Begins in-order verification on the mocked types/instances that were invoked while executing code under test.

  • Method Details

    • withArgThat

      @Nullable protected final <T> T withArgThat(@NonNull org.hamcrest.Matcher<? super T> argumentMatcher)
      Applies a Hamcrest argument matcher for a parameter in the current expectation.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      argumentMatcher - any org.hamcrest.Matcher object
      Returns:
      the value recorded inside the given Hamcrest matcher, or null if there is no such value to be found
      See Also:

    • with

      @Nullable protected final <T> T with(@NonNull Delegate<? super T> objectWithDelegateMethod)
      Applies a custom argument matcher for a parameter in the current expectation.

      The class of the given delegate object should define a single non-private delegate method (plus any number of helper private methods). The name of the delegate method doesn't matter, but it must have a single parameter capable of receiving the relevant argument values.

      The return type of the delegate method should be boolean or void. In the first case, a return value of true will indicate a successful match for the actual invocation argument at replay time, while a return of false will fail to match the invocation. In the case of a void return type, the actual invocation argument should be validated through a suitable JUnit/TestNG assertion.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      objectWithDelegateMethod - an instance of a class defining a single non-private delegate method
      Returns:
      the default primitive value corresponding to T if it's a primitive wrapper type, or null otherwise
      See Also:

    • withAny

      @NonNull protected final <T> T withAny(@NonNull T arg)
      Same as withEqual(Object), but matching any argument value of the appropriate type (null included).

      Consider using instead the "anyXyz" field appropriate to the parameter type: anyBoolean, anyByte, anyChar, anyDouble, anyFloat, anyInt, anyLong, anyShort, anyString, or any for other reference types.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      arg - an arbitrary value which will match any argument value in the replay phase
      Returns:
      the input argument
      See Also:

    • withCapture

      @Nullable protected final <T> T withCapture(@NonNull List<T> valueHolderForMultipleInvocations)
      Captures the argument value passed into the associated expectation parameter, for each invocation that matches the expectation when the tested code is exercised. As each such value is captured, it gets added to the given list so that it can be inspected later. Apart from capturing received argument values, this method has the same effect as the any argument matcher.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      valueHolderForMultipleInvocations - list into which the arguments received by matching invocations will be added
      Returns:
      the default value for type T
      See Also:

    • withEqual

      @NonNull protected final <T> T withEqual(@NonNull T arg)
      When passed as argument for an expectation, creates a new matcher that will check if the given value is equal to the corresponding argument received by a matching invocation.

      The matcher is added to the end of the list of argument matchers for the invocation being recorded/verified. It cannot be reused for a different parameter.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(value) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Usually, this particular method should not be used. Instead, simply pass the desired argument value directly, without any matcher. Only when specifying values for a varargs method it's useful, and even then only when some other argument matcher is also used.

      Type Parameters:
      T - the generic type
      Parameters:
      arg - the expected argument value
      Returns:
      the given argument
      See Also:

    • withEqual

      protected final double withEqual(double value, double delta)
      Same as withEqual(Object), but checking that a numeric invocation argument in the replay phase is sufficiently close to the given value.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Parameters:
      value - the center value for range comparison
      delta - the tolerance around the center value, for a range of [value - delta, value + delta]
      Returns:
      the given value
      See Also:

    • withEqual

      protected final float withEqual(float value, double delta)
      Same as withEqual(Object), but checking that a numeric invocation argument in the replay phase is sufficiently close to the given value.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Parameters:
      value - the center value for range comparison
      delta - the tolerance around the center value, for a range of [value - delta, value + delta]
      Returns:
      the given value
      See Also:

    • withInstanceLike

      @NonNull protected final <T> T withInstanceLike(@NonNull T object)
      Same as withEqual(Object), but checking that an invocation argument in the replay phase is an instance of the same class as the given object.

      Equivalent to a withInstanceOf(object.getClass()) call, except that it returns object instead of null.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      object - an instance of the desired class
      Returns:
      the given instance
      See Also:

    • withInstanceOf

      @Nullable protected final <T> T withInstanceOf(@NonNull Class<T> argClass)
      Same as withEqual(Object), but checking that an invocation argument in the replay phase is an instance of the given class.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      argClass - the desired class
      Returns:
      always null; if you need a specific return value, use withInstanceLike(Object)
      See Also:

    • withNotEqual

      @NonNull protected final <T> T withNotEqual(@NonNull T arg)
      Same as withEqual(Object), but checking that the invocation argument in the replay phase is different from the given value.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      arg - an arbitrary value, but different from the ones expected to occur during replay
      Returns:
      the given argument value
      See Also:

    • withNull

      @Nullable protected final <T> T withNull()
      Same as withEqual(Object), but checking that an invocation argument in the replay phase is null.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Returns:
      always null
      See Also:

    • withNotNull

      @Nullable protected final <T> T withNotNull()
      Same as withEqual(Object), but checking that an invocation argument in the replay phase is not null.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Returns:
      always null
      See Also:

    • withSameInstance

      @NonNull protected final <T> T withSameInstance(@NonNull T object)
      Same as withEqual(Object), but checking that an invocation argument in the replay phase is the exact same instance as the one in the recorded/verified invocation.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      object - the desired instance
      Returns:
      the given object
      See Also:

    • withSubstring

      @NonNull protected final <T extends CharSequence> T withSubstring(@NonNull T text)
      Same as withEqual(Object), but checking that a textual invocation argument in the replay phase contains the given text as a substring.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      text - an arbitrary non-null textual value
      Returns:
      the given text
      See Also:

    • withPrefix

      @NonNull protected final <T extends CharSequence> T withPrefix(@NonNull T text)
      Same as withEqual(Object), but checking that a textual invocation argument in the replay phase starts with the given text.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      text - an arbitrary non-null textual value
      Returns:
      the given text
      See Also:

    • withSuffix

      @NonNull protected final <T extends CharSequence> T withSuffix(@NonNull T text)
      Same as withEqual(Object), but checking that a textual invocation argument in the replay phase ends with the given text.

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      text - an arbitrary non-null textual value
      Returns:
      the given text
      See Also:

    • withMatch

      @NonNull protected final <T extends CharSequence> T withMatch(@NonNull T regex)
      Same as withEqual(Object), but checking that a textual invocation argument in the replay phase matches the given regular expression.

      Note that this can be used for any string comparison, including case insensitive ones (with "(?i)" in the regex).

      When an argument matcher is used for a regular (ie, non-varargs) parameter in a call to a mocked method/constructor, it's not necessary to also use matchers for the other parameters. So, it's valid to mix the use of matchers with given values. Any arguments given as literals, local variables, or fields will be implicitly matched as if withEqual(Object) had been used. In the special case of a varargs method, however, this flexibility is not available: if a matcher is used for any regular parameter, or for any element in the varargs array, then a matcher must be used for every other parameter and varargs element.

      Type Parameters:
      T - the generic type
      Parameters:
      regex - an arbitrary (non-null) regular expression against which textual argument values will be matched
      Returns:
      the given regex
      See Also: