...
This is especially important in unit tests as these may be the only tests where some of those exception scenarios can be tested.
| Note |
|---|
Simply Simple dependencies (e.g., POJOs) or dependencies that are difficult to mock out (e.g., file system, static utility classes) can be used directly without being mocked, as long as doing so doesn't go against the basic testing best practices. |
...
A Lot of Repeated Test Code
See Write Clean And and Re-Usable Test Code
Creating Mocks Manually
See Use Existing Test Tools and Frameworks
...
Repeated Given, When or Then sections in a BDD test, or difficult to name tests are usually two good indicators that a test is doing too much.
Comment:
...
| Note |
|---|
When testing behaviors that build on top of each other |
...
(e.g., test step A, then test step B after step A has been done, etc.), consider extracting the common steps into private methods or external support class. This will reduce code duplication while ensuring that each test method verifies a specific behavior. |
Anti-Patterns
Sleeps
Sleeps in tests should be avoided as they open the door to timing issues and race conditions, slow tests down and are a major cause of test flakiness.
...
Undoing Setups in Specific Tests
Common test fixtures that are run before all or each tests should remain common to all tests and should not be undone by individual tests. Doing so introduces a lot of confusion when reviewing, changing or maintaining the tests.
Instead, code that is common to many but not all tests should be extracted to one or more private methods or external support class to eliminate duplication.
Tests Need to be Run in a Specific Order
...