This chapter was written around the idea of providing you with good practices that would make it easier for you to write and maintain concurrent applications written in Kotlin. Let's summarize the topics and practices discussed in this book so far, so that they stay fresh in your mind:

• There are two important principles when it comes to tests for concurrent code: throw away assumptions, meaning write tests for scenarios that should not happen to make sure that your app is resilient; and focus on the forest, not the trees, meaning that when testing for concurrency, you have to work on Functional Tests that allow you to replicate both the expected and the unexpected from a higher level.
• More advice on testing: always write tests for a bug when fixing it; analyze if a bug can be replicated in places where it has not been reported and write tests to cover those scenarios. Write tests that matter; consider the resiliency requirements as part of your design and test for resiliency; use branch analysis to make sure that your tests are heterogeneous enough; learn when to write Functional Tests and when to write unit tests; and always hide your dependencies behind an interface—this will help during testing by allowing you to provide mocks transparently. There are, of course, other well-known advantages of using interfaces, including allowing you to inject dependencies and facilitating new implementations of a functionality.
• Use the -Dkotlinx.coroutines.debug debug flag to have Kotlin append the ID of the coroutine to Thread.currentThread().name so that your logs are easier to analyze.
• Use the flag when debugging your code, and get used to having a variable watch with the thread name on your debugger so that you always have the coroutine and thread information at first glance.
• Always give a name to long-lasting coroutines; this will make debugging easier.
• Use conditional breakpoints both when testing ephemeral and long-lasting coroutines; that way you can focus your analysis on just the coroutines that you are interested in.
• The only way to guarantee that an application is stable is by having the right tests for it. It's up to the developer to write and maintain tests that meet the expected quality of the application and that really add value to the project.

By this point of the book, I hope to have helped you learn enough to start writing concurrent applications using Kotlin. But the journey hasn't ended yet. In order to completely be able to write effective concurrent code, it's important that you know the inner workings of Kotlin's concurrency. In the next chapter, we will explore how all of this works behind the scenes, and with that you will have a complete picture that should allow you to understand the concurrent code that you are writing at all levels.