[TIP] while on the subject of unittest...
fuzzyman at voidspace.org.uk
Mon Sep 21 03:55:07 PDT 2009
Fernando Perez wrote:
> If someone is improving it, it would be great if this could be cleaned
> up, in TestProgram.parseArgs we have:
> if len(args) == 0 and self.defaultTest is None:
> self.test = self.testLoader.loadTestsFromModule(self.module)
> and then later:
> def createTests(self):
> self.test = self.testLoader.loadTestsFromNames(self.testNames,
> So basically if you want to control how tests are created, you can't
> just override createTests, because parseArgs also does test creation
> (but only sometimes, depending on certain conditions).
> I think that parseArgs should perhaps only parse args, and createTests
> should only create tests, but I'm weird like that :) For the case
> above, it could set a flag that createTests can then later use to
> decide what to do, but parseArgs shouldn't be doing test creation IMO.
That sounds like a reasonable request - although I'm marginally
unsympathetic to people who are subclassing TestProgram in the
firstplace as it is an abomination that should never have existed. :-)
At some point I'd like to deprecate TestProgram altogether and replace
it with something less horrible.
All the best,
> I'm really pleased to see that the unconditional sys.exit() is now
> controllable, thanks!!!
> All in all, I'm super excited to see unittest get better, many many
> thanks to all doing the work, we need it badly. It would be great if
> doctest got a bit of love too, it seems to have gone into
> non-maintenance. At least I looked at the new maintainers file, and
> it said "tim peters - inactive", that worries me for functionality
> that's so important and a module that I know could use some cleanup.
> But I have no idea if doctest is in the crosshairs of the current
> unittest team, I'm just dreaming here :)
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
More information about the testing-in-python