Message203295
| Author |
Gregory.Salvan |
| Recipients |
Gregory.Salvan, michael.foord, ncoghlan, rbcollins |
| Date |
2013年11月18日.14:38:13 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1384785494.56.0.149196031493.issue19645@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Actually unittest assertions depends on testcase class forcing us to extend it to add assertions and to use it to make assertions outside tests.
Seeing interests in rethinking the way assertions are done in unittest, this issue first intent to collect feedback in order to suggest an implementation that fit the most.
Some notes from private discussions:
- it was briefly discussed here #18054.
- taking care of popular solutions like py.test's rich assert
statements and the testtools matcher objects.
- avoid unnecessary complexity, staying focused on value
My opinion:
- must not change unittest api
- may be put in a seperate package (splitting "unittest" in "unittest" and "assertions")
- Open to hide assertions exceptions in optimized mode or providing a simple way to change default behaviour (log, skip... instead of throwing unhandled exception). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2013年11月18日 14:38:14 | Gregory.Salvan | set | recipients:
+ Gregory.Salvan, ncoghlan, rbcollins, michael.foord |
| 2013年11月18日 14:38:14 | Gregory.Salvan | set | messageid: <1384785494.56.0.149196031493.issue19645@psf.upfronthosting.co.za> |
| 2013年11月18日 14:38:14 | Gregory.Salvan | link | issue19645 messages |
| 2013年11月18日 14:38:13 | Gregory.Salvan | create |
|