Ok, --failfast would be nice too :D, I think I remember seeing a
ticket on that.  So make that 4 features from nose...

Which would be great if the test is third or fourth in the stack.  If
it's the last test in 50, it would loose it's effectiveness.

I know, I know.  If you are running 50 tests you can reduce that down
to the module that is causing the problem.

Maybe time would be better spent making the use of nose really super
easy.

In settings.py:

TEST_RUNNER = 'django.contrib.test.nose.run_tests'

There might be some futzy bits to make that actually work, but I think
it'd doable.

Eh?

Rob

On Sep 29, 1:23 pm, Rob Madole <robmad...@gmail.com> wrote:
> Yep, I use the pdb stuff too.  That would be handy.
>
> The way this works in nose is through the testid plugin. Typically you
> do this:
>
> nosetests --with-id --failed
>
> This will create a file called .noseids in the current working
> directory.
>
> You can make it use something else by saying:
>
> nosetests --with-id --id-file=/somewhere/else/.noseids --failed
>
> As far as storing the data of which test failed for Django, I'm not
> sure what the *best* approach would be.  Ned Batchelder's coverage
> module does a similar thing.  It keeps a .coverage file in the root I
> think.  Maybe just call ours .failedtests.  Kinda gross, and not my
> first choice, but it would work.
>
> Or, perhaps use Python's tempfile module.  But I'm not sure how to
> grab a hold of the temp file again for the second pass through (maybe
> tempfile.NamedTemporaryFile but this has problems on some platforms
> according to the docs).
>
> On one hand, I can see this argument: If you are adding 3 features
> from nose, why not just use nose.  But setting up nose and Django to
> use it as the test runner isn't trivial the last time I checked.
> We're using buildout to ease the pain.
>
> Thanks for the input.
>
> Rob
>
> On Sep 29, 12:58 pm, Simon Willison <si...@simonwillison.net> wrote:
>
>
>
> > On Sep 29, 5:03 pm, Rob Madole <robmad...@gmail.com> wrote:
>
> > > I've been using nose for our tests, and one of the features that I
> > > really like is the ability to run the tests again but filter only the
> > > ones that caused a problem.
>
> > > I'm thinking it would look something like this
>
> > > ./manage.py test --failed
>
> > > Does this sound worthwhile to anybody?
>
> > I don't understand how this works - does it persist some indication of
> > which tests failed somewhere? If so, where?
>
> > If we're talking about features from nose, the two I'd really like in
> > Django's test runner are --pdb and --pdb-failures:
>
> > --pdb = when an error occurs, drop straight in to the interactive
> > debugger
> > --pdb-failures = when a test assertion fails, drop in to the debugger
>
> > Cheers,
>
> > Simon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to