Use in Test-driven Development
Programmers working with the test-driven development (TDD) method make use of mock objects when writing software. Mock objects meet the interface requirements of, and stand in for, more complex real ones; thus they allow programmers to write and unit-test functionality in one area without actually calling complex underlying or collaborating classes. Using mock objects allows developers to focus their tests on the behavior of the system under test (SUT) without worrying about its dependencies. For example, testing a complex algorithm based on multiple objects being in particular states can be clearly expressed using mock objects in place of real objects.
Apart from complexity issues and the benefits gained from this separation of concerns, there are practical speed issues involved. Developing a realistic piece of software using TDD may easily involve several hundred unit tests. If many of these induce communication with databases, web services and other out-of-process or networked systems, then the suite of unit tests will quickly become too slow to be run regularly. This in turn leads to bad habits and a reluctance by the developer to maintain the basic tenets of TDD.
When mock objects are replaced by real ones then the end-to-end functionality will need further testing. These will be integration tests rather than unit tests.
Read more about this topic: Mock Object
Famous quotes containing the word development:
“Understanding child development takes the emphasis away from the child’s character—looking at the child as good or bad. The emphasis is put on behavior as communication. Discipline is thus seen as problem-solving. The child is helped to learn a more acceptable manner of communication.”
—Ellen Galinsky (20th century)