On Thu, Jan 15, 2009 at 07:44:00AM +1100, René Dudfield wrote: > it can be good to mark your slow tests somehow, so you can run them > separately. > > With pygame we extend the python unittest module to allow specifying > tags(categories) for tests. This allows us to also use interactive > tests, and other tests you may not want to run every time. > > However you could just move them into a different directory, and > change your test runner to look in a different directory given a cmd > line option... you don't need any fancy testing framework. I prefer phrasing it as "Python lets you trivially create your own fancy testing framework in 15 minutes". ;-) > doctests can be a quick way to do testing. You can create your code > in the interactive interpreter, then paste the output into the doc > strings. You can use doc tests, and unittests together too... so the > doc tests can be run in a unittest test runner. This is, in fact, my preferred mode of testing. Example: http://mg.pov.lt/pyspacewar/trac/browser/trunk/src/pyspacewar/tests/test_world.py (I dislike long doctests in the docstrings of real functions, they obscure the code too much and make it hard to read. Short doctests there are fine. Long doctests belong in a separate test module.) > On Thu, Jan 15, 2009 at 5:57 AM, Jake b <ninmonkeys@xxxxxxxxx> wrote: > > I say 'compiling', because I found a method in the python cookbook that says > > "you want to ensure your modules tests are run each time your module is > > compiled." > > > > It pretty much does "if module is imported, but not main script, and needs > > recompile(because was changed): then run tests" This sounds very interesting. Do you have a URL? I tried searching on http://code.activestate.com/recipes/langs/python/, but didn't find anything. Marius Gedminas -- Writing setattr hooks properly is a black art. Writing persistent setattr hooks is more like hearding bees blindfolded... -- Casey Duncan
Attachment:
signature.asc
Description: Digital signature