Follow the Postgres brick road: a journey of testing against a real database server
Tests are good. Code that uses a database is good. Testing code that uses a database is great… But it's not so easy to do well. Let's follow our journey through various pitfalls to make testing against a local PostgreSQL instance informative, reliable and fast, so that we have fewer horrible surprises once code gets to production.
We follow the usual approach for building an application: store data in a database. Our method is SQLAlchemy models in our Python code, and migrations to evolve the schema.
We also have the usual desire for these applications: they should work, and continue to work as we make changes. One key method is automated tests.
Managing both of these at once is surprisingly subtle, but it's also good to solve: no-one likes having behaviour in production be a surprise because a test made incorrect assumptions about how the database behaves.
I’ll walk us along our database testing trail, stopping in at attractions like (not) using SQLite, ensuring migrations and models match, efficiently instantiating databases with the right schemas, isolated and parallel execution, and even optimising how each individual tests runs.
Huon is a software engineer aiming to make others more effective. He's now writing and deploying Python extensively at ExoFlare, and has previously worked on dev tools and programming languages at Mozilla and Apple and machine learning research at CSIRO.