PyLucid unit tests

Testing PyLucid follows Django's testing framework. Preparation of test environment has following additions:

  • Test database is populated with PyLucid's default pages, templates and styles.
  • Internal plugins are installed.
  • Fully initialized database is dumped to a temporary file and that file is used as default fixture for test cases.

Running tests

Unit tests can be run using utility:

./ test

By default, this will run every test found in tests-subdirectory. If you only want to run tests from particular file under tests/-directory, add the application name to the command line. For example:

./ test sha1_js_login

You can be even more specific and add name of the test case and even method to the command line:

./ test sha1_js_login.TestUserModels

./ test sha1_js_login.TestUserModels.test_normal_test_user

Writing tests

PyLucid unit tests are stored in pylucid/tests/-directory. During the test setup procedure that directory is scanned for .py-files, and test suites are tried to be loaded from them. Note: Subdirectories are not included in search of unit test.

Pylucid.tests module provides custom TestCase class which provides some additional functions over django.test.TestCase and specifies test data fixture created during initialization of test environment. Thus pylucid.tests.TestCase is the preferred class to subclass for new unit tests which require access to PyLucid database. However, it has one drawback compared to unittest.TestCase, it is slower to execute. This is due to fact that at the start of each test case, before setUp() is run, Django will flush the database, and then the fixtures containing PyLucid initial data are loaded. This flush/load procedure is repeated for each test in the test case, so you can be certain that the outcome of a test will not be affected by another test, or by the order of test execution. Thus, if your test case does not need access PyLucid database, using standard unittest.TestCase as a parent class for test case will lead to faster test execution.

The test database

Tests that require a database (test cases inherited from tests.TestCase) will not use your "real" (production) database. A separate, blank database is created for the tests. This is by Django test framework see: Django documentation for details.

Regardless of whether the tests pass or fail, the test database is destroyed when all the tests have been executed.

Further reading

Testing Django applications
Python unittest -- Unit testing framework

A place for improvement

Current test system does not support doctests.

Other test scripts


In this directory are some usefull script for testing something without a browser. Its only for developer to play with any API.


Here you can find only some "server_tests" for troubleshooting