On 5 March 2013 20:02, Lennart Regebro <regebro at gmail.com> wrote: > On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins > <robertc at robertcollins.net> wrote: >> So that is interesting, but its not sufficient to meet the automation >> need Barry is calling out, unless all test suites can be run by >> 'python -m unittest discover' with no additional parameters [and a >> pretty large subset cannot]. > > But can they be changed so they are? That's gotta be the important bit. In principle maybe. Need to talk with the trial developers, nose developers, py.test developers etc - to get consensus on a number of internal API friction points. > What's needed here is not a tool that can run all unittests in > existence, but an official way for automated tools to run tests, with > the ability for any test and test framework to hook into that, so that > you can run any test suite automatically from an automated tool. The, > once that mechanism has been identified/implemented, we need to tell > everybody to do this. I think the command line is the right place to do that - declare as metadata the command line to run a packages tests. > I don't care much what that mechanism is, but I think the easiest way > to get there is to tell people to extend distutils with a test command > (or use Distribute) and perhaps add such a command in 3.4 that will do > the unittest discover thingy. I remember looking into zope.testrunner > hooking into that mechanism as well, but I don't remember what the > outcome was. Agreed. -Rob -- Robert Collins <rbtcollins at hp.com> Distinguished Technologist HP Cloud Services
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4