...
Tests should have names that clearly indicate the behavior and state being tested, and should make it easy to determine what failed without having to look at the test's implementation. For instance, catalogReturnsMetacardIdWhenIngestSucceeds or exceptionThrownWhenInvalidUserNameProvided.
Question:
...
| Note |
|---|
JavaDoc comments should be used when capturing a test's state and behavior in the test method name would make it too long. JUnit 5 |
Test Positive and Negative Scenarios
...
- Assert that the expected value is returned
- Assert that the object under test is in the expected state
- Verify that the mocked dependencies were called/not called as expected
- Verify that all the mocked dependencies that were called were called with the right parameters
- Have just enough assertions and verifications to prove that the test passes, but no less
Never Assertions and verifications should be repeated in different tests only when they are required to verify the behavior being validated. In other words, separate tests should never assert or verify the same behavior in more than one test.
Brendan Hofmann This should be reworded so it doesn't unintentionally exclude interacting permutations of otherwise identical behaviors.
Tracy Batie (Deactivated) Clarify that this is not across test layers, e.g., unit tests and component tests.
| Note |
|---|
This best practice applies mostly to unit and component tests. Since End to End tests tend to be more complex and time consuming, it sometimes makes sense to verify related behavior in a single tests. This should however be avoided where possible as doing so will make it more difficult to determine why a test failed. |
Mock Dependencies
When writing unit or component tests, mock all dependencies that may fail. This allows the tests to guarantee that the unit or component under test behaves as excepted when one of its dependencies fails.
...