« Automating tests in Django | Easily packaging and distributing Django apps with setuptools and easy_install »
Okay, Well I have been hacking away at django-testmaker for the last couple of days based on some ideas from the community. It has gotten a lot better, so here is another blog post showing what's new.
First let me just say how awesome the Django community is, and I am really beginning to understand (and appreciate!) the open source ethos. I would never have gotten this code this good in 3 days without releasing it to the public. Thanks everyone for looking over it and giving feedback!
Here is another video of it in action:
Step 1: Add testmaker to your INSTALLED_APPS settings.
Step 2:
In the directory above the APP that you want to test, run
./manage.py testmaker -a APP
This should tell you where it is logging to, and where the fixture files are going. It should only make fixtures once, so if you change something in your database, you need to go ahead and delete the old fixtures file and it will re-create a new one. It also has 3rd grade file-naming heuristics built in. So if a tests directory exists in your project, it will log to APP-testmaker.py, if there is no tests.py in your APP directory, it will put itself in that file. If you have an existing tests.py file, it will make a tests-testmaker.py file. You will then need to take the contents of this file and integrate it into your normal tests. In a future version if it encounters a tests.py, it may make a tests directory and put both files inside of that, but I don't know if that is a good idea.
Step 3:
Once you have reconciled the above changes (only necessary if you previously had a tests.py file in your APP directory)
./manage.py test APP
Then you have awesome base-line tests for your app.
In my release post I had some comments about the usefulness of these tests. I think that it is a very useful thing if you have an existing body of code with no tests. This will give you a non-trivial base to then at least have tests for your code.
Testing all of your views will also presumably alert you to errors introduced in your models and URLConf files as well. Having dedicated tests to testing models is still better and a good idea, but this code will at least give you a good starting point.
Being able to automate a base-line level of tests for an app will hopefully make people more inclined to include these basic tests in their apps, and everyone knows tests are better than no tests.
Also, the POSTing stuff hasn't been well tested, so there might be a few bugs in that, it is pretty rudimentary.
Posted at 3:21 p.m. on July 26, 2008
Comments: 3
Tags: django , screencast , testing , testmaker
4 days Ago (Comments: 4)
Debugging Django in Production Environments
4 days, 14 hours Ago (Comments: 8)
Should reusable apps have templates?
5 days, 15 hours Ago (Comments: 3)
6 days, 14 hours Ago (Comments: 11)
Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence.
- Unknown


Comments
1 says...
I've got a workaround for the satchmo problem I came up against if you want it?
Posted at 11:06 a.m. on July 27, 2008
2 says...
@David, sure. I don't know the logging module too well yet, so I'd love to hear how to use it better (or not use it at all :)
Posted at 3:39 p.m. on July 27, 2008
3 says...
@Eric: What I did wasn't particularly clever, but it seemed to work with my Satchmo setup:
http://dpaste.com/hold/67837/
Basically, all I'm doing is using debug() instead of info()
Posted at 8:18 a.m. on July 28, 2008