Scope of use of Mock Objects
The actual object is uncertain.
Actual object is difficult to establish
Active object is difficult to produce (such as a network error)
The actual object is very slow.
Active object has one or a UI
to sum up:
This chapter describes a technology called Mock Objects that allows us to isolate unit tests from other domain objects or environments. When writing a good unit test, the biggest obstacle is to abstract yourself from the enforcement environment. We often hear such complaints "I didn't test this method because I was difficult to simulate the real environment." Hoho, it may not be.
In most cases, Write Mock-Object test has a good side effect: he forces you to override some code. In fact, the code is often written. You have created unnecessary coupling between classes and environments. Due to Mock Objects, you must think with the previously different thinking and apply better design patterns, such as interface and control reverse (IOC)
Mock Objects should not only be a unit test technology and regardless as a design technology. Method Theory is called "Test-Driven" in a rising star, and his supporters write the code before writing. With TDD, you don't need to refactor your code to adapt to test: The code is already in the test.
Although it is easy to write Mock Objects, when you need to simulate thousands of objects, he can become annoying. In the following chapters, we will show many open source frameworks, these frameworks can automatically generate Ready for your class. -to-use mocks makes it very pleasant to use Mock-Objects strategies.
In the following chapters, CACTUS will be introduced, followed by some J2EE test cases, including Servlet, Filter, JSP, Taglibs, Database, and EJB.
