Login

Tag "test-runner"

Snippet List

Test runner that installs 'tests' packages as apps

Ever tried to unit test custom fields or abstract models? If so, you probably used a solution like [this one](http://djangosnippets.org/snippets/2843/). It surely works, but it has some issues: 1. Runs 'syncdb' several times. 2. It's not automatic. You must add the mixin or copy the code to each of the TestCases. This test runner adds to INSTALLED_APPS the 'app.tests' package for **each of the specified** apps, **before the 'syncdb' happens**. This has the [discovery runner](https://pypi.python.org/pypi/django-discover-runner) as a dependency (for 1.5 only, it will be the default in 1.6). However, it comes as a mixin so it should be easily pluggable to other test runners. If you intend to use the mixin with other runners, note that it imports 'app.tests.models' so it won't work with tests modules (tests.py). Your runner must "use" test packages (like discovery runner). # USAGE # in your settings.py: TESTAPPS_INSTALL = ( 'app1', 'app2', # ... ) TEST_RUNNER = 'testapp_runner.DiscoverTestAppRunner' # example import path # extra apps in command line. # run test for apps 'app1' to 'app4', adding 'app3' and 'app4' to the TESTAPPS_INSTALL setting. manage.py test app1 app2 app3 app4 --with-test-app=app3 --with-test-app=app4

  • django
  • testing
  • apps
  • testrunner
  • test-runner
  • app-models
Read More

Deep package test runner

**NOTE: This is modified from 1.0's test runner and has only been tested on Django 1.0 + Python 2.5** This is a test runner that searches inside any app-level "tests" packages for django unit tests. Modules to be searched must have names that start with "test_" (this can be changed by modifying `get_multi_tests()`, [`mod.startswith('test_') and mod.endswith('.py')`]). It also allows for arbitrarily nested test packages, with no restrictions on naming, so you could have: myapp/ +- tests/ +- __init__.py +- test_set1.py +- category1/ +- __init__.py +- test_something.py +- subcat/ +- __init__.py +- test_foobar.py +- category2/ +- __init__.py +- test_other.py and "manage.py test myapp" would pick up tests in all four test_*.py test modules. Searching the modules in this way, instead of importing them all into the top-level `__init__.py`, allows you to have "name collisions" with TestCase names -- two modules can each have a TestFooBar class, and they will both be run. Unfortunately, this snippet doesn't allow you to specify a full path to a specific test case or test module ("manage.py test myapp.category1.test_something" and "manage.py test myapp.test_set1.TestFooBar" won't work); using "manage.py test myapp.TestFooBar" will search out all test cases named "TestFooBar" and run them. "manage.py test myapp.TestFooBar.test_baz" will work similarly, returning the test_baz method of each TestFooBar class. To use, put this code in "`testrunner.py`" in your project, and add `TEST_RUNNER = 'myproject.testrunner.run_tests'` to your `settings.py`.

  • tests
  • test-runner
  • package
Read More

Continuous Integration command

This command, `runtester` will run the test suite whenever files are modified. It takes the apps to test as arguments; if no apps are given the entire test suite is run. Use this command just as `runserver` is used; fire it up in a shell and it does its thing. Copy this snippet into `django/core/management/commands/runtester.py`.

  • testing
  • tests
  • commands
  • command
  • test-runner
Read More

3 snippets posted so far.