On 16 kesä, 09:29, Russell Keith-Magee <[email protected]>
wrote:
> On Thu, Jun 14, 2012 at 6:51 PM, Anssi Kääriäinen
>
> <[email protected]> wrote:
> > On 14 kesä, 13:35, Chris Wilson <[email protected]> wrote:
> >> I've made some improvements (in my view) to the DjangoTestSuiteRunner. I
> >> got tired of having to remember my test class names and of typing so much:
>
> >> ./manage.py test binder.BinderTest.test_can_create_users
>
> >> This new version searches for tests with the given name in all
> >> INSTALLED_APPS, so you can just type this:
>
> >> ./manage.py test test_can_create_users
>
> > A big +1 to easier running of single tests. I haven't checked the
> > implementation / API details at all. But I do know I would have
> > immediate use for this feature in running Django's tests.
>
> 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? 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?
>
> 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 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 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.
2. I am editing some test, and want to then run it. I don't have the
full test identifier anywhere easily copy-pasteable, and here this
feature would help me - I could copy-paste the method name, try to run
it, and if multiple matches were found I would get the full test
identifier and could then run that.
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.
- Anssi
--
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.
