> For the complete documentation index, see [llms.txt](https://dotnetweb30-ke.gitbook.io/ke/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dotnetweb30-ke.gitbook.io/ke/verification/automated-testing-principles-patterns-and-practices/test-double-patterns.md).

# Test double patterns

**Test Double:** How can we verify logic independently when code it depends on is unusable? How can we avoid Slow Tests? \
We replace a component on which the SUT depends with a “test-specifi c equivalent.”

## Test Stub

We replace a real object with a test-specifi c object that feeds the desired indirect inputs into the system under test.

![](/files/-Lk9-DDOhDzpCPUV1H5t)

## Test Spy

We use a Test Double to capture the indirect output calls made to another component by the SUT for later verification by the test.

![](/files/-Lk9-iMztKpWE7iRrft-)

## Mock Object

We replace an object on which the SUT depends on with a test-specifi c object that verifi es it is being used correctly by the SUT

![](/files/-Lk9-vjfCs-Uekxe8tTF)

## Fake Object

We replace a component that the SUT depends on with a much lighter-weight implementation.

![](/files/-Lk908ET0ERmt0TVbFT4)

## Configurable Test Double

We confi gure a reusable Test Double with the values to be returned or verifi ed during the fi xture setup phase of a test.

![](/files/-Lk90O6OcoNeCiA7qwID)

## Hard-coded Test Double

We build the Test Double by hard-coding the return values and/or expected calls.

![](/files/-Lk90a0pnFpmaC23yqlw)