test_doubles
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| test_doubles [2025/09/09 18:57] – plida | test_doubles [2025/09/09 19:02] (current) – plida | ||
|---|---|---|---|
| Line 51: | Line 51: | ||
| When a test knows too much about the inner workings of the class (what methods are called and in what order). The slightest refactoring can break such a test. | When a test knows too much about the inner workings of the class (what methods are called and in what order). The slightest refactoring can break such a test. | ||
| + | ==== Best practices ==== | ||
| + | - Choose a correct test double. | ||
| + | - Give preference to fake where it's appropriate, | ||
| + | - Limit the amount of mocks. If a test requires more than 2-3 mocks, something went wrong. | ||
| + | - A test must fixate the business-result, | ||
| + | - Take out the creation of doubles into factories or test data builders. This improves readability. | ||
| + | - Use mocks/fakes for unit-tests, for integration -- real services. | ||
| + | - Use clear names (SpyEmail, FakeRepo). | ||
test_doubles.1757444237.txt.gz · Last modified: by plida