@Capturing. Their effect is to extend and/or constrain the mocking capabilities here specified. Any type can be mocked, except for primitive and array types. A mocked instance of that type is automatically created and assigned to the mock field/parameter, for use when recording and/or verifying expectations. For a mock field, the test itself can provide the instance by declaring the field as
finaland assigning it the desired instance (or
null). The effect of declaring a
@Mockedtype, by default, is that all new instances of that type, as well as those previously created, will also be mocked instances; this will last for the duration of each test where the associated mock field/parameter is in scope. Also, all non-
privatemethods of the mocked type will be mocked. When the mocked type is a class, all super-classes up to but not including
java.lang.Objectare also mocked. Additionally, static methods and constructors are mocked as well, just like instance methods; native methods are also mocked, provided they are
protected. When mocking an
java.lang.Enumbase class is not mocked by default. If needed, however, base types like
Enumcan be mocked by explicitly declaring a mock field or mock parameter of the specific base type. While a method or constructor is mocked, an invocation does not result in the execution of the original code, but in a (generated) call into JMockit, which then responds with either a default or a recorded result (or with a constraint violation, if the invocation is deemed to be unexpected). Mocking will automatically cascade into the return types of all non-
voidmethods belonging to the mocked type, except for non-eligible ones (primitive wrappers,
String, and collections/maps). When needed, such cascaded returns can be overridden by explicitly recording a return value for the mocked method. If there is a mock field/parameter with the same type (or a subtype) of some cascaded type, then the original instance from that mock field/parameter will be used as the cascaded instance, rather than a new one being created; this applies to all cascading levels, and even to the type of the mock field/parameter itself (ie, if a method in class/interface "
A" has return type
A, then it will return itself by default). Finally, when new cascaded instances are created, @Injectable semantics apply. Static class initializers (including assignments to
staticfields) of a mocked class are not affected, unless specified otherwise.
|Modifier and Type||Optional Element and Description|
Indicates whether static initialization code in the mocked class should be stubbed out or not.
public abstract boolean stubOutClassInitialization
static finalfields initialized with compile-time constants are not assigned at runtime, remaining unaffected whether the class is stubbed out or not.) By default, static initialization code in a mocked class is not stubbed out. The JVM will only perform static initialization of a class once, so stubbing out the initialization code can have unexpected consequences. Static initialization will occur the first time the class is instantiated, has a static method called on it, or has a static field whose value is defined at runtime accessed; these are the only events which prompt the JVM to initialize a class. If the original class initialization code was stubbed out, then it will not be there to be executed at the time of static initialization, potentially leaving static fields
nulland later causing
NullPointerException's to occur.