Given the massive span of JMockit’s feature set this article certainly wasn’t intended to be exhaustive. My primary goal was to offer the most compelling and fundamental advantages of JMockit over other non-instrumentation based mocking tools to my colleagues both from the point of view of generating interest but also to provoke thought and also naturally to provide examples as a spring board. I’ll certainly take on board your suggestions for other aspects of JMockit that are interesting and perhaps do another article on them.

Your comments are very gratefully received. Thanks for stopping by.

I eventually figured out that Maven only finds test classes whose names end in “Test”, so I renamed them.

With that, Maven finds all test classes and runs them, but fails because neither tools.jar nor “-javaagent:jmockit.jar” was specified. Assuming a JDK 1.6 environment, the best option here is to add the following dependency to the pom.xml:

        <dependency>
            <groupId>com.sun</groupId>
            <artifactId>tools</artifactId>
            <version>1.6.0</version>
            <scope>system</scope>
            <systemPath>${java.home}/../lib/tools.jar</systemPath>
        </dependency>

With this, all tests ran succesfully in my environment. (Remember to remove/change the “skipTests”, though.)

I spotted a few small mistakes, though:

• In MockPrivateMethod, an invocation is recorded for User#name(), but later (in the replay phase) the test never calls the method. The test passes because the expected field value was set directly on it, and then read in the “assert”. Instead, the calls to “setField” and “getField” could be removed, with the last line becoming assertEquals("fred", Deencapsulation.invoke(user, "name"));.
• In MockDefaultConstructor, the Mockit.redefineMethods was used when it should be Mockit.setUpMock or Mockit.setUpMocks (a MockUp class would also do). “redefineMethods” is an older method (Core API) which knows nothing about the @Mock and @MockClass annotations (it could be used in tests written with JDK 1.4 code).
• The same occurs in MockStaticInitialiserBlock. BTW, a nicer way to apply the MockUserInitialiser mock class would be to annotate the test class with @UsingMocksAndStubs(MockUserInitialiser.class).
• In VerifyInternalMethods, the “@Mocked” field should be of type User, not UserService. With that, the userService.populateUser(); line inside the verification block should be removed.
• With regard to verification blocks, they are used to verify non-strict expectations only, which are those recorded inside a NonStrictExpectations block, or belonging to a @NonStrict mocked type, or like in this case when no invocations at all are recorded for the mocked type. All other cases are strict expectations, which are verified by JMockit implicitly and do not allow “unexpected” invocations.

There are other insteresting features not mentioned in the article, as well:

• Local mock fields (declared inside expectation blocks) and mock parameters in test methods.
• Delegate objects passed to the “returns” method.
• Argument matching fields, which allow you to write user.setAge(anyInt); instead of user.setAge(withAny(1));.
• The @Capturing annotation, which tells JMockit to mock unspecified implementation classes on demand, as they are loaded by the JVM.

“The Java compiler does not preserve instance initializers as separate elements in the class file, instead inserting any statements in such blocks into each and every constructor, right after the necessary call to the superclass constructor. Therefore, it is not possible to separately mock instance initialization blocks.

Of course it’s not a limitation as such because JMockit can mock constructors but it is interesting.

int i;
{ i=2;}

Introduced in Java 1.3 for Anonymous classes. They get inserted into every constructor of the class at runtime. Its not possible to define a constructor for an Anonymous class but they are given a default constructor. The static initializer is inserted into that constructor giving you a way to initialize things in Anonymous classes. I don’t know how it gets from the bytecode, to the constructor at runtime, but I would guess its not part of the actual class as such. Go on…how does it work?

    @Override
    public void run() {
        try {
            produceFilteredFiles(this.rootSearchFolder, this.fileProcessor, this.folderFilter);
        } catch (InterruptedException ex) {
            logFailure(LOG, ex);
            Thread.currentThread().interrupt();
        } finally {
            logExit(LOG);
            filesProducedCdl.countDown();
        }
    }