This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Julian
Recipients Julian, aliles, ezio.melotti, michael.foord, ncoghlan, serhiy.storchaka
Date 2013-06-04.03:26:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Can I throw in, and hopefully not in a way that's too out of place, that I think that unittest might want to rethink it's strategy re: assertion methods? The fact that the object that has all the assertions and the object that has the logic for running a test, and the thing that holds all the tests on it, makes things difficult. For a concrete example, subclasses of unittest.TestCase like e.g. trial.unittest.TestCase do not have easy ways of allowing pluggable assertions, by which I mean you can't show up and say "Here I have a thing with some assertions, use this". So, for trial, if we want to support unittest2 assertions (which I'd personally like), we have to put code in trial to do so.

It would seem to me that it'd be nicer to (obviously keep what we have for backwards compatibility) but rather than adding a bunch of mixins, have an API that decouples things holding assertion methods from a TestCase, and mix those in by calling a method on the TestCase rather than mixing in a bunch of assertion mixins.

(also, in a slightly lighter note, I might like an assertEqualAndAlsoNotUnequal method :D)
Date User Action Args
2013-06-04 03:26:18Juliansetrecipients: + Julian, ncoghlan, ezio.melotti, michael.foord, aliles, serhiy.storchaka
2013-06-04 03:26:18Juliansetmessageid: <>
2013-06-04 03:26:18Julianlinkissue18054 messages
2013-06-04 03:26:18Juliancreate