Unittesting with CubicWeb

In test driven developpement (TDD), you write the test before you write the code. On a web application, number of levels can be tested. Here are a few hints at how we manage some of the testing with CubicWeb.

We use pytest (which is an extension of python's unittest framework available in logilab-common) to execute all tests across the cubes. Even in the core of cubicweb the tests are spread out across the server, web part, repository, common tools... so a simple pytest command crawls though all theses tests and runs them.

The problem : One of the tricky things with testing CubicWeb is that the structure of the data is imported into the database (which enables us to easily modify the schema on running data), and that test data can be long to generate and fake for a web application that is used to talk to a proper database server (postgres). So we though of inserting test data into an sqlite database. After a bit of work on compatibility, it was up an running. But setting up that database was (and still is) quite long, testing was becoming way too long, TDD (with frequent testing) was becoming impossible.

The solution : we ended up storing the sqlite database in a temporary file which is used up if it's not too old, TDD was back in the loop. So if you're developing for CubicWeb don't worry about those test/tmpdb files, on the contrary, that means you're running tests. For writing tests, check out the content about it in the book.