Mockito is a mocking framework that tastes really well. It lets you write beautiful tests with clean & simple API. Mockito doesn't give you hangover because the tests are very readable and they produce clean verification errors. Read more about features & motivations.
Writing unit tests can be hard and sometimes good design has to be sacrificed for the sole purpose of testability. Often testability corresponds to good design, but this is not always the case. For example final classes and methods cannot be used, private methods sometimes need to be protected or unnecessarily moved to a collaborator, static methods should be avoided completely and so on simply because of the limitations of existing frameworks.
PowerMock is a framework that extend other mock libraries such as EasyMock with more powerful capabilities. PowerMock uses a custom classloader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods, removal of static initializers and more. By using a custom classloader no changes need to be done to the IDE or continuous integration servers which simplifies adoption. Developers familiar with EasyMock will find PowerMock easy to use, since the entire expectation API is the same, both for static methods and constructors. PowerMock extends the EasyMock API with a small number of methods and annotations to enable the extra features. From version 1.1 PowerMock also has basic support for Mockito.
When writing unit tests it is often useful to bypass encapsulation and therefore PowerMock includes several features that simplifies reflection specifically useful for testing. This allows easy access to internal state, but also simplifies partial and private mocking.
AtUnit minimizes boilerplate code in unit tests and guides test development by enforcing good practices.
* mark exactly one field with @Unit to indicate the object under test.
* mark fields with @Mock or @Stub to obtain mock objects
* inject your tests, and your test subjects, using your favorite IoC container
Mock Objects Integration
AtUnit integrates with JMock or EasyMock to provide mock objects:
* obtain a JMock context simply by declaring a field
* annotate fields with @Mock to obtain JMock or EasyMock mock objects
* annotate fields with @Stub to obtain a JMock or EasyMock stub object
... or you can use your own mock objects plug-in with two easy steps:
* implement the MockFramework interface
* annotate your tests with @MockFrameworkClass(MyMockFramework.class)
Container Integration
AtUnit integrates with Guice or Spring to take all of the work out of dependency-injected tests.
With Guice:
* never see the Injector, never write bootstrapping boilerplate!
* @Inject test class fields without even defining a Module
* declaratively obtain mock objects with @Inject @Mock
* if you need more binding flexibility, simply have your test class implement Module
With Spring:
* annotate fields with @Bean to get them from the Spring context
* fields annotated with @Bean which do not appear in your Spring context are added to it automatically! (This includes @Mock and @Stub fields.)
* AtUnit looks for a Spring XML file with the same name as your test, or you can specify the location yourself with @Context("filename")
* Most of the time, you don't even need a Spring XML file!
You can easily plug in other containers in two steps:
* implement the Container interface
* annotate your tests with @ContainerClass(MyContainer.class)
ClassMock is a framework that helps the creation of unit tests for components that use reflection or annotations. In this kind of classes, the behavior is dependent of the class structure. This way, each test case usually works with a different class created specifically for the test. With ClassMock is possible to define and generate classes in runtime, allowing a better test readability and logic sharing between tests.
Spring AutoMock is a test enabling framework to allow automatic exposure of Mocked beans for a Spring application. Used in conjunction with Spring autowiring of bean dependencies you can develop teired application contexts that represent the architectural tiers of your application, and thus you testing strategy. The simplest example is a separation of service beans and DAO beans into separate xml application contexts so that the services can be fully tested in isolation of the DAOs. The DAO beans are still required by the services typically as an injected property. Spring AutoMock can automatically register a Mock and a proxy of certain beans, so that the Mocks can be injected into your test cases and the matching proxy into the item under test. This reduces the need for repeated Spring test configuration.
The mock-object testing pattern has commonly been used to test an individual unit of code without testing its dependencies. While this pattern works well for interaction-based testing, it can be overkill for state-based testing. Learn how to streamline your unit-testing using stubs and the pseudo-objects testing pattern.
A small mock library that is extremely easy to learn with plenty of examples. Only has 5 classes for the api. This library's best feature is being able to test a 24 hour timer in milliseconds with a mockobject timer.
Java mocking is dominated by expect-run-verify libraries like EasyMock or jMock. Mockito offers simpler and more intuitive approach: you ask questions about interactions after execution. Using mockito, you can verify what you want. Using expect-run-verify libraries you are often forced to look after irrelevant interactions.
SevenMock is a light-weight Java dynamic mock objects framework. It is unusual in that it places responsibility for verifying operation parameters directly on the unit test code. This enables the test designer to write very clear, precisely targeted tests and makes test failures easier to diagnose.
RMock 2.0.0 is a Java mock object framework to use with jUnit. RMock has support for a setup-modify-run-verify workflow when writing jUnit tests. It integrates better with IDE refactoring support and allows designing classes and interfaces in a true test-first fashion.
Mock is a widely used technology in unit test domain. It shields exteral and unnecessary factors and helps developers focus on the specific function to be tested.
EasyMock is a well known mock tool which can create mock object for given interface at runtime. The mock object's behavior can be fine defined prior the test code in the test case. EasyMock is based on java.lang.reflect.Proxy, which can create dynamic proxy class/object according to the given interfaces. It has the inherent limitation from the Proxy. It can create mock object for given interface only.
Mocquer is a similar mock tool as EasyMock. With the help of Dunamis Project, it extends the function of EasyMock to support mock object creation for both class and interface.
JMock is a library that supports test-driven development1 of Java2 code with mock objects3.
Mock objects help you design and test the interactions between the objects in your programs.
The jMock library:
* makes it quick and easy to define mock objects, so you don't break the rhythm of programming.
* lets you precisely specify the interactions between your objects, reducing the brittleness of your tests.
* works well with the autocompletion and refactoring features of your IDE
* plugs into your favourite test framework
* is easy to extend.
To someone who is new to unit testing, the idea of mock objects can be confusing to say the least. I have covered in previous tutorials how to use various mock object frameworks (EasyMock and jmockit). However in this tutorial, we will focus on the concept of mocking in general. What is a mock object? What is it used for? Why can't I mock object XYZ? Let's look into these questions and maybe clear a bit of the air on the use of mock objects.
JMockit Core consists of a single class with a small set of static methods, which allow arbitrary methods and constructors of any other class to be replaced with mock implementations at runtime.
This facility can be used for writing unit or integration tests, enabling the isolation of code under test from other parts of the codebase. This approach is an alternative to the conventional use of "mock objects" as provided by tools such as EasyMock and jMock.