This is an example app for my presentation "Mocks aren’t Stubs. What are test doubles and how do we use them?"
The goal of the application is to show how we can use different kinds of test doubles in different situations. The app provides a random interesting fact about cats by retrieving it from a public API, evaluating the truthfulness of this fact, and calculating a score.
How it works: We fetch a fact about cats from the public API. Then, we use an algorithm to assess the reliability of the fact, based on a fact’s score. Finally, the app generates an output that includes the fact with the opinion and the score.
We are going to cover only few cases from the requirements:
- should fetch a fact about cats
- should assess the fact’s truthfulness and give a score
- should log incorrect interactions with the public API
- when a received JSON is unexpected (a business requirement):
- notify ‘CTO’ about the problem via email
- notify ‘programmers’ about the problem via email
- notify ‘programmers’ about the problem via slack
- ...
Disclaimer This application is supposed to be as demonstrative as possible. Therefore, it lacks separation of concerns (responsibilities) with clear boundaries, a flexible output, a mechanism for managing dependencies, etc. On the other hand, the app's logic is gathered in one place - the randomFact() method and its internal calls.
Let's examine possible test cases for our requirements:
Fetcher component
- an expected JSON (happy path)
- error requesting data with unspecified reason (fail path)
- error requesting data due to a timeout (fail path)
- an empty JSON (exceptional condition)
- an invalid JSON (exceptional condition)
- an unexpected JSON (exceptional condition/edge case)
Assessor component
- an expected string (happy path)
- an empty string (edge case)
Assessor component | Test doubles |
---|---|
an expected string | stub / real implementation / never mock |
an empty string | stub / real implementation |
The MIT License (MIT). Please see the License file for more information.