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.