...
Always remember to tests all positive and negative scenarios and ensure that the proper results (error code, exception, message, etc.) are returned.
| Warningnote |
|---|
Some error scenarios are extremely difficult to test using end-to-end or component tests, which makes testing all exception scenarios at the unit test level even more critical. |
Keep Related Tests Together
Try to keep tests that relate to a similar behavior together inside the test class. This makes it easier for other people to determine what's already been tested and what needs more testing.
Use Proper Assertions and Validations
...
| 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 if possible as doing so will make makes it more difficult to determine why a test failedwhat the issue is. |
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.
...
Use Existing Test Tools and Frameworks
Do not re-invent the wheel. Every homegrown mock, test tool or framework needs to itself be tested and maintained. There are tons of good testing frameworks and tools out there, use those instead.
Write Clean and Re-Usable Test Code
Maintain testing code as you would production code. This means keep the test code clean and extract re-usable code when it makes sense to do so.
Tests Before Changes
Before changing, fixing a bug or refactoring existing code, always make sure that tests exist and pass first.
If not, write unit test tests for the code that is about to be changed or refactored.
...
| Info |
|---|
Refactorings automatically performed by an IDE are usually safe and may not require adding tests first. This is especially true for simple structural refactorings that do not affect the logic or flow of the code, such as extract class, extract method, etc. If such refactorings make writing the tests easier, then applying them without existing tests can be considered. |
Be Test-Driven
Brendan Hofmann - I'm not sure I agree with this one. A lot of development is iterative in nature, and TDD can make that more expensive. We should have best-practices beyond TDD as well.
Steve Lombardi (Deactivated) - This seems OK but I wouldn't want developers to loose the flexibility to work how they work best.
Comment:
- Make it clear this is just a recommendation and doesn't always apply.
- Add "when appropriate" or "for new code" in title or description?
Follow Try tollow the Test-Driven Development Test CycleCycle when it makes sense and feel comfortable with it.
First, come up with an initial list of end to end, component and/or unit tests that will be needed to show that the user story, requirement or improvement works as expected or issue has been fixed.
...
Test behaviors, not methods or lines of code.
Comment:
...
This includes exceptional (e.g., error or unexpected) behaviors.
Write each test following the Behavior-Driven Development structure, i.e., Given/When/Then. In other words make sure each test:
...