|
It's okay to rely on things like system settings and database content, but in general if your functions are simpler, they are easier to test.
For the love of God, keep writing these atcirles.
== Details specific to OpenHatch ==
=== We regularly run Automated Testing ===
OpenHatch's Automated Testing is run by Hudson, with the interface on the linode server @ http://linode2.openhatch.org:8080/
=== Where to write your tests ===
In general, add tests to the same Django ''app'' as you are editing. For example, if you made
changes to '''base/views.py''', then add a test in '''base/tests.py'''.
The test files are kind of ''sprawling''. It doesn't really matter where within the ''tests.py'' file
you add your test. I would suggest adding it to the end of the file.
=== The OpenHatch test case helper class ===
In '''mysite/base/tests.py''' there is a TwillTests class. It offers the following convenience methods:
* '''login_with_client'''
* '''login_with_twill'''
=== About fixtures ===
If you inherit from TwillTests, you get some data in your database. You can rely on it.
=== To run your tests ===
What app did you write your test in? Let's pretend it was in '''base''':
./bin/mysite test base
That's a mold-berkaer. Great thinking!
=== To run just a few specific tests ===
./bin/sqlite_mysite test base.Feed base.Unsubscribe.test_unsubscribe_view
The structure here is '''app'''.'''class'''.'''method'''. So if you want to just run
your own new test, you can do it that way.
=== Mocking and patching ===
This section is important, but we haven't written it yet. Oops.
=== Testing with Twill, versus the Django test client ===
To make a long story short:
The Django test client is good at introspecting how the function worked internally.
Twill tests are good because they let you say "Click on the link called '''log in'''".
We should write more about this. Maybe you, dear reader, can say some more.
|