Description
Last year at PyConZA I presented a talk about different approaches to test setup and alluded to an idea that we have been playing with at Reahl: class based test Fixtures. We have since refined our approach and built it as an add-on that works with py.test.
In this talk I briefly introduce Fixtures again for people who did not see the last year's talk. I then show more detail about the types of problems we deal with while testing and how our fixture ideas solve these issues.
For example, in our tests the database schema is created from scratch at the beginning of a test run, but the database is kept clean by rolling back a transaction between each individual test. We can also create extra temporary database tables, just for a test run.
We integrate Selenium webdriver with our web server so that the web server runs in the same thread as the tests themselves, in the same database transaction. The effect of this is that when something breaks inside the web server, the test immediately breaks as well, and gives a sensible stack trace.
In our code, we use a global context much like what Flask does. This is a design often criticised because of the fact that it makes testing difficult. We use our fixtures to hide the associated complexities regarding the global context as well.
The talk covers some details about how we use Fixtures to provide this functionality and some thoughts on where we found it useful and which things we still struggle to deal with elegantly.