You are maybe like me: I never learned at school how to write tests. Myteachers gave me at first a broad overview of computer history. Then,they explained me some basic design patterns. And to finish, I often hadto write more or less basic programs, to validate and demonstrate myskills. Not the kind of code I would be really proud of today: theprocrastinator monkey living in my head at this time was more thinkingabout planning my summer holidays, rather than writing Ninja code!And to make things worse, my studies focused on network and systemengineering. Not software architecture. Funny story, because I decidedto become programmer a couple of years later…What I realize now is that I don’t have as much time as before to learn.And in a world driven by business, where time is money, and wheretradeoffs are the rule, there is rarely enough money to write both shinynew features and a complete test suite.People who practice Test-Driven Development know how complicated it canbe to write proper tests. TDD is often discouraging at first: thelearning curve is steep. But this problem also exists in the testingworld in general. Because writing good tests is hard, many beginners getheadaches trying to reach this goal. How to convince project managers tohave more time for writing tests in these conditions…But “le jeu en vaut la chandelle” as we say in French ('the juice isworth the squeeze'). Well tested applications are not only easier tomaintain and extend. They also have in general a better API. That’s whatwe will see in this talk, by focusing on how to write integration tests.Our journey will begin with a presentation of different testingstrategies. We will then jump to the practical part, using Pytest,interface testing , dependency injections and stubs, amongst manyothers. And because we want to add nice buzzwords on our resume afterPyConDE, we will finish this talk by automating the whole with DockerCompose.