...
| Table of Contents |
|---|
Best Practices
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 the Test-Driven Development Test Cycle.
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.
Then for each one:
- Add a test
- Run all tests and see if the new test fails
- Write the code
- Run the tests until they pass
- Refactor the code as needed
- Move on to the next test
Be Behavior-Driven
Test behaviors, not methods or lines of code.
Comment:
- May need to clarify that "exceptional" behaviors can be included and how
- Mention that test names should also be from a behavior perspective
Write each test following the Behavior-Driven Development structure, i.e., Given/When/Then. In other words make sure each test:
- First provides a clear context in which it will be run (given)
- Performs the operation to be tested (when)
- Asserts that the expected outcomes have been met (then)
Use Clear Names
Tests should have names that clearly indicate the behavior and state being tested. For instance, catalogReturnsMetacardIdWhenIngestSucceeds or exceptionThrownWhenInvalidUserNameProvided.Joseph North I think test names should include the state under test as well as the expected behavior.
Question:
- Do we care about long test names? How do we handle those? JavaDoc?
- Refer to long name smell?
- Failing test name should let you know what failed exactly without having to look at the test code.
...
| Warning |
|---|
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
...
Use Proper Assertions and Validations
...
| 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 the Test-Driven Development Test Cycle.
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.
Then for each one:
- Add a test
- Run all tests and see if the new test fails
- Write the code
- Run the tests until they pass
- Refactor the code as needed
- Move on to the next test
Be Behavior-Driven
Test behaviors, not methods or lines of code.
Comment:
- May need to clarify that "exceptional" behaviors can be included and how
- Mention that test names should also be from a behavior perspective
Write each test following the Behavior-Driven Development structure, i.e., Given/When/Then. In other words make sure each test:
- First provides a clear context in which it will be run (given)
- Performs the operation to be tested (when)
- Asserts that the expected outcomes have been met (then)
Smells
Tests Difficult to Name
...