Gary Poster wrote:
On Jan 12, 2007, at 6:33 PM, Marius Gedminas wrote:
On Fri, Jan 12, 2007 at 05:17:18PM -0500, Benji York wrote:
Marius Gedminas wrote:
I have implemented a --list-modules option in a branch. It causes the
test runner to apply package and module name filters, and then print
list of Python module names that would be imported. It is very fast
because it doesn't actually import the modules. It is not very
because it does not pay attention to test name patterns or layer
Would this option be useful to anybody?
If its output were identical to the tests that were actually going to be
selected, then I think it'd be worth including.
That would be the proposed --list-tests option, wouldn't it?
Or do you want a list of modules that have at least one test remaining
after all the filtering (including --layer, --level and --test) is done?
I might use --list-modules for test-running debugging (i.e., it's not
finding my test--is it because it is not finding my module, or what?).
That said, I can imagine more helpful tools for that use case (i.e., a
way to verbosely list all filters in play...if there's not already
something like that).
That's a good use case for --list-modules, the only one I can see
frankly. I'd really like --list-tests and wouldn't mind having to wait
the extra five seconds to get an "accurate" list.
So what's your use cases for all of these?
* to see whether your test is actually found and run
* to see whether certain test selection mechanisms work the way you
expect them to
http://worldcookery.com -- Professional Zope documentation and training
2nd edition of Web Component Development with Zope 3 is now shipping!
Zope3-dev mailing list