Hi all,
On Mon, 18 Jun 2012, Anssi Kääriäinen wrote:
> On 16 kesä, 09:29, Russell Keith-Magee <[email protected]>
> >
> > Well, sure -- easier is better -- but is this actually going to be
> > easier? Are you saying that you've never written two test classes with
> > the same test name?
I don't think I have, but I don't mind either. The cost of accidentally
running an additional unnecessary test (which should pass) is very low,
about 1 second, compared to remembering the class name of the test. Also
it's a good incentive to give your tests unique names :)
> > Just looking at code I've got right now -- I've
> > got a dozen tests named "test_bad_date" scattered throughout my test
> > suite. How do I disambiguate between them?
You can still run tests the old way if you want to. The only difference is
that if you do something that was previously invalid, i.e. specify a
simple label that's not a package, it will search for tests instead of
aborting.
> > We already have a problem with namespace collapsing -- if you have two
> > test classes with the same name in an app, you can't differentiate
> > between them. I'd rather not compound the problem by removing class
> > names from the discovery process as well.
I'd rather not be forced to add yet another component to the test label
when running it from the commnd line. Running tests should be as quick and
easy as possible.
> I guess this should work by giving a message like this on test name
> clash: "ERROR: Multiple tests found: <list of test identifiers>". The
> user could then copy-paste the correct test and run the test by full
> identifier.
I might deliberately want to run multiple tests in some cases. I was
thinking of adding wildcard search support too. It shouldn't be an error,
it should be explicitly supported.
> I have two specific needs for this feature:
> 1. When a test errors, I want to have as-easy-as-possible way to
> rerun that test. This could be achieved by just adding a line
> containing the full test identifier
> ("queries.Queries1Tests.test_something") in the error output. We
> currently don't have that, instead you need to collect pieces from the
> test output.
That's true, and annoying, but also requires using the mouse to rerun
tests. That's where the Bash completion extension would be useful, I
guess.
> I guess Jannis is right - this and the "record errors / replay" feature
> belong to third party test runner. When we know the API is correct, then
> adding these to core would make sense to me. But, as we can easily test
> these outside core, lets start there.
Fine by me. How about a contrib test runner? And does anyone have time to
write some tests for a test runner?
Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cambridge City FC, Milton Road, Cambridge CB4 1UY
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
--
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?hl=en.
