Mockito - simpler & better mocking

Mocks Aren't Stubs The term 'Mock Objects' has become a popular one to describe special case objects that mimic real objects for testing. Most language environments now have frameworks that make it easy to create mock objects. What's often not realized, however, is that mock objects are but one form of special case test object, one that enables a different style of testing. In this article I'll explain how mock objects work, how they encourage testing based on behavior verification, and how the community around them uses them to develop a different style of testing. I first came across the term "mock object" a few years ago in the Extreme Programming (XP) community. But as often as not I see mock objects described poorly. This difference is actually two separate differences. Regular Tests I'll begin by illustrating the two styles with a simple example. These two behaviors imply a couple of tests, these look like pretty conventional JUnit tests. Tests with Mock Objects Using EasyMock class OrderStateTester...

Unit testing with mock objects Unit testing has become widely accepted as a "best practice" for software development. When you write an object, you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate. When you're dealing with simple data or service objects, writing unit tests is straightforward. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again. Mock in the middle The common coding style for testing with mock objects is to: Create instances of mock objectsSet state and expectations in the mock objectsInvoke domain code with mock objects as parametersVerify consistency in the mock objects While this pattern is very effective for many cases, sometimes the mock object cannot be passed into the object being tested.