Continuous Integration in Django project

Hello my name is Igor Kononuchenko. I'm leading the development process of Django web startup. I tell about my experience of introducing Continuous Integration to Django project.

Assumption

Relatively small project with a team of four developers. We want to make the process of development as close as possible to the described in the book Continuous Integration: Improving Software Quality and Reducing Risk. There were the following requests:

  • Unit-testing.
  • The code must be checked on standards compliance.
  • Automated project installation(build) on server.
  • Fast test runs(up to 10 second).

Unit-testing

The doctest was rejected immediately(it has few common with TDD). In unit-testing I faced the following problems:

  • The models.py file. The test runner looks for any subclass of unittest. TestCase in this module.
  • A file called tests.py in the application directory -- i.e., the directory that holds models.py. Again, the test runner looks for any subclass of unittest.TestCase in this module from here.

Standard mechanism of test running requires the hard integration of the test in the work project. I am disagree with this. I think that the tests should be separated from production code and situated in a separate folder. Besides I wasn't satisfied with the fact that Django created MySql database for tests that slowed badly the tests runs.

The problem with MySql was solved by changing Mysql to Sqlite (:memory – it uses RAM during testing). The solution was taken from here.

For the reason of the placing all the tests in one folder, the file suite.py was created in the same folder that contained the following code:

Here are two functions from the code above:

For mocking we used the PyMock - it is rather inconvinient with its low informative error messages (inappropriate actions). Maybe there are better libraries.

Checking the code on standards compliance.

For the code checking was used the pep8 utility.

Introduction of this utility caused some dissatisfaction from developers. But it is very useful to keep the code clean.

Build-server.

Somebody can say that Python project doesn't need a build server. I don't know how to name it in another way. In my case it is a Windows server with a TeamCity installed. TeamCity is a rather convenient thing with excellent web interface. It's very simple and fast to configure. It allows to do Pre-tested Commit (in my case it didn't work well). It periodically checks the SVN (we are using it) on the code changing and runs the build script - in my case it is a simple build.bat file which makes update from SVN, runs tests and restarts Apache on our server. From this moment we can open and test the project on the build server. The members of the project are informed about success or fail of the build in depends of notification configuration.

The realities of project (current state) and future plans.

For the team it was the first serious continuous integration project. It was also the first serious django project. The deadline as always was very close. Probably not all development  stages were close to the ideal but the process was started. In plans we want to integrate Selenium tests, and make the automatic deploy to production.

Comments

Thanks for the article,

But how exactly do you hook up the suite.py to the django's testing workflow (i.e. database initialisation etc via "manage.py test [app_name]")?

Thanks

Advertise on this site

Recent Comments