Go Ahead. Mock Me.
Mocking collaborators is the key to keeping unit tests pure and simple.
Soon after a developer has worked through simple unit testing examples, reality hits home ... testing in a production application can be much more difficult. Among the types of tests developers write are integration and unit tests.
Integration tests require implemented and working collaborators of the class-under-test (CUT). (This is also called the "system-under-test [SUT]", "object-under-test [OUT]", etc. Given all the terms, I've thought about coining a more general term, "thing-under-test" or TUT. :-) Often, a database is involved, so tables must be created, dummy data defined, and proper transaction management for testing be implemented. If you're using Spring, the Spring context has to be started. If Hibernate is used, a Hibernate SessionFactory must be instantiated. Application server services may need to be available; i.e. JNDI, JTA, servlet runner, and more. All in all, integration tests are often messy, almost always very slow, and overly fragile in a fast-changing environment.
In contrast, unit tests are supposed to be relatively simple and always fast. They are intended to focus only on the class-under-test without any assumption about the implementation and completeness of the collaborators, the Spring context, Hibernate SessionFactory, database, server services, etc.
How we deal with collaborators in unit tests is the focus of this presentation.
In this presentation, we'll have a code-based discussion on unit test development with the goal of keeping our unit tests simple and fast. Here's what we'll cover:- Working with JUnit 4
- Test Configuration in Projects
- Unit Test Basics: Setup, Exercise, Verify, Teardown
- Testing Obstacles
- Stubs and Mocks
- jMock & EasyMock
- Using Groovy to take the pain out of testing
Presenter: Jack Frosch
Sponsor: Contegix
Meeting Notes: tba
Comments