Snippet List
DB migration support has been added in Django 1.7+, superseding South. More specifically, it's possible to automatically generate migrations steps when one or more changes in the application models are detected. Definitely a nice feature!
I've written a small generic unit-test that one should be able to drop into the tests directory of any Django project and that checks there's no pending migrations, ie. if the models are correctly in sync with the migrations declared in the application. Handy to check nobody has forgotten to git add the migration file or that an innocent looking change in models.py doesn't need a migration step generated. Enjoy!
- testing
- unittest
- database
- migration
The snippet is a modification of [snippet 1315](http://djangosnippets.org/snippets/1315/) to fit the needs for Django 1.3 and 1.4. You can follow the explanations and instructions there.
To plot a nice and so useful call-graph with timings, call:
$ gprof2dot -f pstats unittest.profile | dot -Tpng -o unittest.profile.graph.png
where 'unittest.profile' is the test runners profile output defined in your settings.
- profile
- unittest
- runtime
- cprofile
So you need to change some settings when running an individual test in a test case. You could just wrap the test between `old_value = settings.MY_SETTING` and `settings.MY_SETTING = old_value`. This snippet provides a helper which makes this a bit more convenient, since settings are restored to their old values automatically.
Example usage:
class MyTestCase(TestCase):
def test_something(self):
with patch_settings(MY_SETTING='my value',
OTHER_SETTING='other value'):
do_my_test()
- settings
- testing
- unittest
Ok... this is really a hack. But I love it. I hate setting up all of my test cases into suites, and making sure that I remember to add them each time I add a new python file... annoying! This allows me to have a tests package and then just add python files and packages to that test package (mirroring my app setup). Each of the files are then dynamically imported and every test case is automatically executed. If you don't want one to execute, add it to the ignore list. If you add 'views' to the ignore list, it will ignore all views, otherwise you would have to specify 'package.views' if it is in a package.
So... in short this is a bit ghetto, but it saves me a lot of time just setting up all my tests... now I can just write them! Hope it's useful to someone.
Greg
- dynamic
- unittest
- load
- test
- loader
- loading
- unit
If you would like to see the latest queries you have done when running a unittest, this is not so easy. You have to initialize the queries list and set DEBUG to True manually. Then you have to figure out a way to print the queries you want to see just now and format them. I.e., monitoring queries when doing TDD is a bit of a hassle, and this should help.
This little helper does all this for you; your UnitTest only needs to import django.db.connection and store the current length (offset) of the queries list. Then, using Python's coroutine functionality, all you have to do is send that offset to the QueryPrinter coroutine (which you can, for example, initialize as a global variable or a class variable of your UnitTest) and you get the latest SQL printed as a simple table.
- queries
- unittest
- debugging
- printing
- for
- connection
This test runner is invoked with its own command:
./manage.py quicktest {usual test args follow}
this creates a test database if it needs to and then DOES NOT delete it. subsequent uses of it start with the same database. this is for rapid test/development cycles usually running a single test. a single test can run in less than a second.
when you need to alter the schema simply use the normal ./manage.py test which will delete the old test database and create a fresh one.
it does not replace your normal test runner. it could probably be altered to even use your custom test runner.
there are improvements to be done, and it will be included with a small testy app soon.
A test runner for Django unittests which profiles the tests run, and saves the result. Very useful for diagnosing your apps. Place the top portion of the code into a file called `profiling.py` someplace in your python path. Update your `settings.py` file with the bottom two lines of the code. Now you are ready, so just run `python manage.py test [appnames...]` to test any apps listed with profiling. By default this will just print a nice report after the unittests. If you change the value of `TEST_PROFILE` to a file, the profile will be saved to that file. The latter is recommended because these profiling reports have a lot of info in them, so it is best to tear through them with the `pstats` module.
- profile
- unittest
- cprofile
This is a skeleton framework of a unittest for an app which will write out a fixture of the test database once the test has been done. I run this once for all apps, but you can limit which apps get serialized by modifying the self.apps value from get_apps (all apps) to a list of only certain apps. This script by default assumes that you have a SVN_DIR setting which points to the current working subversion directory, with a subdirectory of fixtures where it places `tests.json` upon completion. You may change this location as well. After running `python manage test` you can run `python manage loaddata fixtures/tests.json` to load in to the real database all of the test database fixtures. Feel free to edit at will, let me know of any changes that are helpful, and dont forget to fill in the `...`s
**Note**: The `--failfast` argument in Django since version 1.2 does this. Use this snippet for earlier versions.
If a large number of your unit tests get "out of sync", it's often annoying to scan through a large number of test failures which overflow the terminal window's scroll buffer.
This library strictly stops after the first failure in a doctest suite. If you're testing multiple applications, it also stops after the first test suite with failures in it. So effectively you'll get one failure at a time.
This code has been tested with doctests only so far. You can also fetch the latest source from [my repository](http://trac.ambitone.com/ambidjangolib/browser/trunk/test/).
I hate when my unittest hits database. Especially when each test case needs different dataset.
So I wrote this db mock, that's local to specific test and uses sqlite3 in-memory db.
Usage (nosetests):
class TestMainNoData(DbMock):
'testing main function with no meaningful data'
def test_no_posts(self):
'there are no posts'
assert models.Post.objects.count() == 0, 'should be no feeds'
- testing
- unittest
- database
- test
I use these helper methods in my unit tests. They turn many simple getting-and-posting tests into one-liners. Definitely a work in progress, and I can't be the only person who has done this sort of thing -- comments are more than welcome.
12 snippets posted so far.