Message254427
| 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. |
|