...

Come up with a list of end to end, component/service and unit tests that will be needed to show that the user story, requirement or improvement work as expected. Write the first the first test(s), run them to see them fail, provide an implementation, run the test(s), refactor and/or fix any problems, rinse and repeat.

Write BDD-Style Tests

Test behavior, not logic. , not Write your tests following the BDD style

Write Clear Tests

Positive and Negative Testing

...

Write tests following the Behavior-Driven Development test structure, i.e., Given/When/Then. In other words, make sure the tests first provide a clear context in which the test will be run (given), then performs the operation to be tested (when), and finally ensures that the expected outcomes have been met (then).

Use Clear Names

Tests should have names that clearly indicate the behavior being tested. For instance, catalogReturnsMetacardIdWhenIngestSucceeds or errorIsReturnedWhenInvalidUserNameIsProvided.

Positive and Negative Testing

Always remember to tests all positive and negative test scenarios and ensure that the proper results (error code, exception, message, etc.) are returned and provided in the later case.

Smells

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.

Some options to avoid sleeps in tests include:

• Replaced the sleep with an active wait loop (a.k.a., polling), i.e., wait until a condition has been met before moving on
• Use external synchronization, i.e., use existing class notification mechanism to know it has reached a certain state before continuing
• Refactor the code under test to eliminate concurrency
• Use external dependency calls or side-effects as synchronization points in the tests