Skip to content
This repository has been archived by the owner on Feb 21, 2021. It is now read-only.
kilgerm edited this page Sep 13, 2012 · 25 revisions

Mockins

Mockins ("mocking instructor") is a code-generator for mock and stub code. It's aim is to assist you when writing unit tests for existing code.

current version

stable: 0.3 development: 0.4-SNAPSHOT

see Downloads for how to get Mockins

News

  • 2012-09-13 holiday's over, recommence coding!
  • 2012-08-09 Mockins 0.3 relased! see Downloads
  • 2012-08-03 Mockins 0.2 released! now also available via maven central, see Downloads
  • 2012-08-02 registered at Sonatype OSS repository so that public snapshots and releases will now get deployed there (currently 0.2-SNAPSHOT)
  • 2012-08-01 Mockins 0.1 released! see Downloads
  • 2012-08-01 started the wiki

Documentation

  • [User Guide](wiki/User Guide)

Mockins is suited for you...

...if you are familiar with the following problem:

  • you have (legacy) code without unit tests
  • naive invocation of the method to test yields a NullPointer
  • reason: some parameter or field may not be null, or may not return null when called
  • but it is far from clear where to start with mocking/stubbing, since there are many dependencies
  • so you best shot is to mock and stub by trial and error...

Mockins is NOT suited for you...

  • ...if you expect it to generate full unit tests (while it is theoretically possible to generate unit tests just having the mocks/stubs detected by Mockins, such tests would not have much value)
  • ...if you intend to use code generated by Mockins as it is, without extending it to a real unit test first

Example:

// This is the class you would like to test
MyClass classUnderTest = new MyClass();

// first, create an "instructor" wrapper
MyClass instructor = Mockins.instructor(classUnderTest);

// then call whatever method you would like to test...
// (you can leave arguments null)
instructor.myMethod(null, null);

Mockins then runs testMethod and tries to add mocks/stubs for null-valued parameters and fields so that the method does not throw a NPE anymore. If it succeeds, the necessary mocks will be output (to stderr) like this:

//============================================================================
// * Mockins result *
//============================================================================

// method call will succeed with the following mocks and stubbings:
SomeOtherClass param0 = Mockito.mock(SomeOtherClass.class);
Mockito.when(param0.getData()).thenReturn("");
Object param1 = null;
classUnderTest.myMethod(param0, param1);

Wait! Isn't code generation evil?

This can certainly be discussed. In the whole, I'd agree with that, but I can see code generation a valid option under the following assumptions:

  • the automatisiation provided by the generation cannot be moved to runtime (clearly, you wouldn't want Mockins to change stubbing on the fly because your code behaved differently)
  • the code would have been written by hand otherwise, in comparable quality
  • the code generation saves you manual effort consisting of predictable, repeatable steps (at least for myself I can say, I did write some test code for legacy software the way: run it once - nullpointer - ok, fix that by adding a mock; next try gives another nullpointer - add a stub here, and so on)

Mocking Frameworks

Mockins supports the following mocking frameworks:

If exactly one of those frameworks is present in the (test) classpath, Mockins will use that one.

Mockins API

  • run Mockins for a certain method:
MyClass instructor = Mockins.instructor(classUnderTest);
instructor.myMethod(null, null);

* manually set the mocking framework:
``` java
Mockins.option().useMockito();

or

Mockins.option().useEasyMock();

For details, have a look at the [User Guide](wiki/User Guide).

Requirements

  • You need a Java 5+ JDK
  • and one of the supported mocking frameworks on your (test) classpath