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 martin.panter
Recipients Gregory.Salvan, Julian, eric.araujo, martin.panter, michael.foord, ncoghlan, r.david.murray, rbcollins, serhiy.storchaka
Date 2015-11-10.02:38:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1447123100.84.0.182016068564.issue19645@psf.upfronthosting.co.za>
In-reply-to
Content
Looking at Gregory and Robert’s “matchers” link, which also covers “assertThat”, it seems to provide a library of matcher assertion objects. E.g. instead of this TestCase-coupled code:

self.assertEquals(something, "expected value")

you would write

from testtools.matchers import Equals
self.assertThat(something, Equals("expected value"))

Implementing a custom matcher (say HasAttr for Serhiy’s first use case) seems to involve creating the HasAttr class with a match() method, and maybe another HasAttrMismatch class (though maybe you could get away with just a shared generic mismatch class?).

It seems to me that if you ignore the vaguely-documented TestCase.failureException attribute, you can fairly easily decouple the existing methods from a TestCase instance:

def assert_equal(first, second, msg=None):
    # Implementation could be copied independently of any test state
    TestCase().assertEqual(first, second, msg)

The matcher scheme would be more flexible though, because you can compose matcher objects.
History
Date User Action Args
2015-11-10 02:38:21martin.pantersetrecipients: + martin.panter, ncoghlan, rbcollins, eric.araujo, r.david.murray, michael.foord, Julian, serhiy.storchaka, Gregory.Salvan
2015-11-10 02:38:20martin.pantersetmessageid: <1447123100.84.0.182016068564.issue19645@psf.upfronthosting.co.za>
2015-11-10 02:38:20martin.panterlinkissue19645 messages
2015-11-10 02:38:19martin.pantercreate