> Unless you can make a particularly convincing case for using an alternative,
> based upon some deficiency of unittest that will adversely affect django
> testing, I'm inclined to stick with whats in the standard library.
To me, possibly due to my own moral failings :), the most compelling
case is the one that speaks to developer laziness. With the nose-django
plugin, nose does right now everything in your proposal, with the
exception of finding non-doctests in models.py. In addition it already
implements a whole bunch of other things that users are going to ask
you for, sooner or later: coverage reports; profiling; package- and
module-level setup and teardown; output capture; generator-based tests;
test functions; tests in classes that don't descend from
unittest.TestCase; skipped and deprecated tests; deep, easy and
flexible test selection; integration with setuptools ("python setup.py
test")... and then there's the plugin system, which allows you to
easily output test results in html or xml, write custom test discovery,
and hopefully lots of other things that I haven't thought of.
nose is LGPLed and easy_installable, and its really just a layer on top
of unittest. FWIW, TurboGears uses nose and integrates it just by
adding the requirement to its setup file and letting setuptools do the
work.
> That said, I am not aiming to set up a django testing framework that
> actively impedes the use of py.test or nose; if there is anything we can do
> to make the two compatible/complimentary, let me know.
The core django test runner is pretty hostile to outside use, mainly
because it wants to run the show and provides no hooks for anybody else
to get in there. So don't do that. :) The most helpful thing I can
think of right now would be to put the test db functions (create,
reset, install app, flush data, drop) someplace accessible so that the
core django test runner can use them and your runner can use them and
the nose-django plugin can use them and anybody else can use them, so
we're all setting up and tearing down the test environment in the same
way. Then if your runner is finding unittests and doctests in
predictable locations, I can tune the nose-django plugin to behave in
the same way, so that the same test suites will be runnable with either
tool.
JP
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
