The general terminology is that stubs have minimal...

# announcements

[fellshard]

The general terminology is that stubs have minimal internal workings - you don't ask them how they were interacted with, they simply interact. You don't, say, ask 'did your fooBuzz() method get called exactly twice?' Instead, you design your system such that interacting with the object is sufficient to determine whether the results were correct.

This generally fails for side-effecting ports at the edge of the system. A write to a database, for example, can't necessarily be stubbed by just returning void. In cases like that, you can still use a stubbing tactic by having the stub store the values written so that it can be examined later.

In short: stubs are used to dumbly implement behaviour of a more complex subsystem, and may hold minimal state that can be inspected for correctness. Mocks are used to test that an object is interacted with in a precise way - that a series of method calls is made with expected values. This makes stubs valuable for many types of tests, and can even be used to test the system in full operation if robust enough (not always valuable!), while mocks are valuable chiefly for some interaction or integration tests, mostly for systems that force you to use very finicky or precise series of interactions, e.g. a poorly built state machine.