EasyMock Summary

Prev don't be afraid of buying books Next

EasyMock Summary One very important advantage of EasyMock is that the mock is specified in the test. This means that the mock is tightly bound to the test it serves. There are some downsides to using EasyMock, though: There's a performance hit that you take at runtime. It takes some time to build the mock on the fly. As you specify the mock, you not only specify what methods are mocked, but also the expectations. This rolls two steps into one. This makes the mocks easier to build and more localized, but means that unique mocks need to be built for each test, since each test will have different expectations to verify. You are limited to the mocks as EasyMock creates them. When you handcraft mocks or use MockMaker you can tweak the mock as required. Not being able to tune expectations may lead to over-specification in tests. There may be cases where you only really want to test one parameter. If you are hand-coding you just write an expectation-setting method that does just that. If you are using MockMaker you can tweak the generated methods, or add what you need. With EasyMock you are stuck with expectations fully specifying exactly the methods in the interface being mocked. EasyMock-generated mocks are passive: you specify expected calls and provide return values. There is no way to have the mock make calls into your objects. This generally isn't a problem. When it is, use MockMaker or build it by hand. You can only mock interfaces with EasyMock whereas MockMaker will generate mocks for classes as well. This can be an issue if you are creating mocks for legacy code that wasn't designed in an interface-centric way. EasyMock only works with Java 1.3.1 or later due to its reliance on new classes in the java.lang.reflect package, specifically InvocationHandler and Proxy.

	Amazon