09-20, 14:55–15:30 (Europe/Amsterdam), Van Gogh
Our software and services often have closely linked dependencies. When writing python unit tests, one tends to mock away these dependencies (i.e. database call). Mocking - while great in some scenarios - has some drawbacks as well. At Nicolab we have embraced testcontainers for a lot of these situations. I would like to show you this tool that offers you the possibility to easily spin up your own containers representing your external dependencies and use them in your test, without ever having to leave your python / pytest environment.
Our software and services often have closely linked dependencies. At Nicolab - a company specialising in acute stroke care assisting software - this is no exception. We have embraced writing tests using testcontainers in (most) cases we have external dependencies. External dependencies we often deal with in our services are a message bus, cloud storage and a relational database.
In some of our older code, we used to mock away these dependencies, simply specifying the response we wanted in every unit test. The testcontainers package allows us to easily spin up a container from within our unittest code, and assert against that actual dependency. This allows you to write integration tests quite easily from your service repo, fully embedded in your python code.
In this talk, I would like to tell you why we have embraced testcontainers at Nicolab. But as we all know, no tool is perfect for every job. As such, we'll also look at when not to use it, and simply mock away to your hearts content. Since this will be my first PyData talk, and I am naïve, we will also do a little live demo where we look at some running tests that use testcontainers.
It will be a light and accessible talk, and I hope it has something of value in it for everyone that writes the occasional test.
My first introduction to code was Fortran 90 during my (Hydro)Geology studies. It was not love at first sight. This changed when I picked up R and Python to automate some processes in my day to day job, still working in the Geology field. I noticed that the little coding projects I gave myself I found the most enjoyable, and as such, decided to jump aboard the Data train, back in 2015. Being a Data Sciencist back then was already the sexiest job, and I wanted a piece of that. I joined the NPO (Dutch public broadcaster), and have since joined Nicolab, where I currently work as a Data/Software Engineer on developing solutions to assist in the acute stroke space.
Also: come and tap me on the shoulder if you wanna talk Mountainbiking and/or Padel :-) <3.