Test doubles serve various purposes like indirect input provisioning, recording of indirect output, or immediate verification of interactions. So it can hardly be surprising that there are quite a few different types of double patterns. This section introduces them and gives examples of hand-written implementations, which should be a precious experience for a deep comprehension and the correct application of stand-in components.
To get a component into a state that constitutes a test's precondition, it is sometimes necessary to satisfy dependencies to collaborators which do not actually contribute to the functionality under test. The only right to exist for these DOCs is to fill in argument lists to avoid input verifying exceptions or the like. Because of this, it is superfluous for the stand-in to provide any real functionality. A test double that serves this role is denoted as dummy.
Let's assume our enhanced Timeline constructor checks whether...