Description
You are maybe like me: I never learned at school how to write tests. My teachers gave me at first a broad overview of computer history. Then, they explained me some basic design patterns. And to finish, I often had to write more or less basic programs, to validate and demonstrate my skills. Not the kind of code I would be really proud of today: the procrastinator monkey living in my head at this time was more thinking about planning my summer holidays, rather than writing Ninja code!
And to make things worse, my studies focused on network and system engineering. Not software architecture. Funny story, because I decided to 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 where tradeoffs are the rule, there is rarely enough money to write both shiny new features and a complete test suite.
People who practice Test-Driven Development know how complicated it can be to write proper tests. TDD is often discouraging at first: the learning curve is steep. But this problem also exists in the testing world in general. Because writing good tests is hard, many beginners get headaches trying to reach this goal. How to convince project managers to have more time for writing tests in these conditions…
But “le jeu en vaut la chandelle” as we say in French ("the juice is worth the squeeze"). Well tested applications are not only easier to maintain and extend. They also have in general a better API. That’s what we will see in this talk, by focusing on how to write integration tests. Our journey will begin with a presentation of different testing strategies. We will then jump to the practical part, using Pytest, interface testing , dependency injections and stubs, amongst many others. And because we want to add nice buzzwords on our resume after EuroPython, we will finish this talk by automating the whole with Docker Compose.