Having read this chapter, you should now be able to test your code, and debug it when issues are found.

This chapter described how testing can be done, in a way that is fully automated so that it can be integrated in continuous integration systems. The Python standard library is a solid foundation on which RxPY and asynchronous code can be tested rather easily. You should also understand why pure functions are easier to test than side-effects: they can be fully tested by using dependency injection, which is easier to use than stubs or mocks.

Logging is a subject in-between testing and debugging. It can be useful during the initial testing phases, or when regressions are detected. One major benefit of ReactiveX here is that, once a logging infrastructure is in place, then it becomes easy to configure it dynamically.

Finally, debugging is the dark side of ReactiveX, with no tools dedicated to this task. Using trace points is currently the only way to debug an application. Hopefully, this should change in the future. AsyncIO, on the other hand, provides a simple but efficient tool to detect issues on asynchronous code. Moreover, this tool can be enabled without any change in the application, just by setting an environment variable.

The next chapter will continue our tour of Docker, and explain how it can be used to deploy an application such as the audio transcoder. At the same time, it will revisit the solution used in Chapter 7, Using Third-Party Services, to handle CPU-bound operations.