I consider this chapter particularly important. That is because, in my experience, the only way to guarantee the stability of an application is to have the right tests for it. Here is some advice that isn't necessarily tied to concurrency, but is important to keep in mind anyway:

• The fix for a bug must be accompanied with a test covering the scenario. This is the only way to keep regressions under control; if you don't add a test for the fix you just made, then eventually the code will be modified in a way that will bring back the bug.
• Always consider how a concurrency bug may affect other parts of the application. Often, a bug will be reported for a specific feature, but because we implement many features in a similar way, that same bug may exist in other places. And if you have even a slight suspicion that it could be happening elsewhere, add a test to validate if it exists—if it doesn't, you have added a test that will prevent it from happening in the future.
• Don't test all the permutations for your concurrent tasks. The objective is not to cover every single scenario, but to find those that challenge assumptions while adding value.
• Talk about resiliency before doing the implementation, and always test for resiliency. I have seen many projects where no one asked what the expected behavior should be in gray scenarios, like only partial information being available. It's important to consider those ahead of time because exception handling is something that you don't want to design after the fact.
• To find edge cases, use the branch analysis from your coverage report. This may not always be useful when testing concurrent code, but it's worth to try. The branch report will let you know if your tests are following the same scenarios always—for example, if, for all your tests, the same path is being executed.
• Learn when to write unit tests and when to write Functional Tests. Functional tests will often require more effort, so it's important to do them when they really add value.
• Wire your dependencies using interfaces—that will ease the job of mocking them to replicate complex scenarios for Functional Tests.