Test Patterns

If you can only test by using these patterns may indicate that the design must improve.

Stub

Are objects that return fixed answers, defined for a specific test, because of performance or security.

• Ex.: Avoiding your tested usecase to invoke a Gateway that sends emails. (With Stubs you overwrite inline (at the test level) the Gateway behavior without having to implement a Fake instance)

You only control de returned data from the stubed function.

Stubs can become difficult to use if you have to stub a lot of methods, and they require data from one another.

A simpler solution then would be to use a Fake.

Spy

Are objects that "spy" on the execution of other methods and save the results to be checked later.

They don't overwrite behavior, you only tap to the execution. (You hove no control over the function call)

• Ex.: Checking in your tested usecase, if it called that spied method. Or which data it returned or was given.

Mock

Are objects similar to Stubs and Spies.

But you can control the function call:

• Also what parameters it will be called.

And you can control what it returns.

Dummy

Are objects that are created only to complete the list of parameters to invoke a specific method.

• Ex.: The code requires you to provide arguments, but it does not have any relevance in the business rule.

Like specifying dummy data for a function.

Fake

Are objects that have implementations that simulate the real instance operation, used in production.

• Ex.: Writing a in-memory database implementation, that follows the same contracts as the default one.

A good code design is required to use fakes, which can/may be simpler depending on the situation.

Fake require more work, since you will have create the Fake class, instanciate it in the test and inject them into the dependant methods.