Message254427
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. |
|
Date |
User |
Action |
Args |
2015-11-10 02:38:21 | martin.panter | set | recipients:
+ martin.panter, ncoghlan, rbcollins, eric.araujo, r.david.murray, michael.foord, Julian, serhiy.storchaka, Gregory.Salvan |
2015-11-10 02:38:20 | martin.panter | set | messageid: <1447123100.84.0.182016068564.issue19645@psf.upfronthosting.co.za> |
2015-11-10 02:38:20 | martin.panter | link | issue19645 messages |
2015-11-10 02:38:19 | martin.panter | create | |
|