On 16.06.2012, at 08: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: >> >> 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. > > Although I'm not a big fan of Nose for testing, this is one thing I > think they've got right -- explicit path naming of tests, not trying > to collapse namespaces in order to make it "easier". Exactly, but I think we can use the included unittest2 discovery for this purpose instead of rolling our own. In that sense I share Carl's concern about our test runner being an oddity compared to the rest of the Python community. Do you see any blockers in moving our test runner in the direction unittest2 has taken? >> Another feature which I would find useful would be "--log-failed- >> cases=somefile". Then you could re-run the failed tests using: >> >> ./manage.py test < somefile >> >> I would find this very useful in fixing regressions - run the full >> test suite - fix regressions - try to run the failed cases - fix more >> - run the failed cases again - when done rerun full test suite. >> >> Anybody else for this feature? > > Bikeshedding, I'd rather just have a single flag that: > * logs to a known location > * searches for the existence of the log when the test run starts; if > the log exists, only run the failed tests > * if the test suite passes without error, deletes the log so that the > next test run executes everything. > > However, +1 to the general idea. "Run the tests that just failed" is a > very common use case for me; it would be nice to have interface > support for it. Don't get me wrong, I also like the idea, but this seems entirely something that would fit the bill of a 3rd party test runner, instead of a built-in feature. At least I haven't had this particular requirement yet and haven't heard of it being a common practice in test driven development (like for example --failfast). Jannis -- 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.
