@Retention(value=RUNTIME) @Target(value={FIELD,PARAMETER}) public @interface Mocked
JMockit Home@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 final and
assigning it the desired instance (or null).
The effect of declaring a @Mocked type, 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 methods of the mocked type will be mocked.
When the mocked type is a class, all super-classes up to but not including java.lang.Object are also mocked.
Additionally, static methods and constructors are mocked as well, just like instance methods.
When mocking an enum type, the java.lang.Enum base class is not mocked by default.
If needed, however, base types like Object and Enum can 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-void methods 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 static fields) of a mocked class are not
affected, unless specified otherwise.stubOutClassInitialization(),
Tutorial| Modifier and Type | Optional Element and Description |
|---|---|
boolean |
stubOutClassInitialization
Indicates whether static initialization code in the mocked class should be stubbed out or not.
|
public abstract boolean stubOutClassInitialization
static final fields 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 null and later causing
NullPointerException's to occur.