A stub is a test double that emulates incoming interactions: calls from the system under test to obtain input data. It supplies configured responses rather than primarily verifying calls. Stubs replace dependencies that are difficult to set up or maintain. section 5.1
Classify test doubles by the interaction they emulate:
- Use a stub for queries that return data without changing dependency state. section 5.1
- Use a mock for commands that produce side effects or change dependency state. section 5.1
- Treat dummy, stub, and fake as stub-like roles; their differences concern sophistication or creation rationale. section 5.5
- Avoid verifying a stub's query call merely because it occurred: the call is usually an intermediate implementation detail, not the result. section 5.5
Returning database data
Configure a database stub so GetNumberOfUsers returns 10, invoke CreateReport, and assert that the report contains 10 users. The result—not the database call—is the meaningful assertion. section 5.1
Figure 5.2. Sending an email is an outcoming interaction: an interaction that results in a side effect in the SMTP server. A test double emulating such an interaction is a mock. Retrieving data from the database is an incoming interaction; it doesn’t result in a side effect. The corresponding test double is a stub.
Contrast retrieving database data as an incoming interaction with sending email as an outcoming interaction. section 5.1
