[Python-Dev] PEP: Consolidating names and classes in the unittest
module (updated 2008-07-15) (original) (raw)
Stephen J. Turnbull stephen at xemacs.org
Tue Jul 15 11🔞05 CEST 2008
- Previous message: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)
- Next message: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ben Finney writes:
Removal of
assert*
namesThere is no overwhelming consensus on whether to remove the
assert*
names or thefail*
names;
7 to 1 is overwhelming in my book. See Message-ID: <loom.20080714T230912-310 at post.gmane.org> From: Antoine Pitrou <solipsis at pitrou.net>
While people's preferences are important, I think there is a very good case to made that keeping this much continuity in the test suite as possible is more so.
- Explicit is better than implicit: The
fail*
names state what the function will do explicitly: fail the test. With theassert*
names, the action to be taken is only implicit.
EIBTI applies with the most force to "local" names, ie, specific to a particular function, class, or program. Here we propose to impose a community-wide convention. I think we can document it explicitly and expect near-instant uptake on the appropriate connotations to "assert" (especially since that connotation is pretty much universal across languages with an assert facility, anyway).
- Avoid false implication: The test methods do not have any necessary connection with the built-in
assert
statement.
Data point: Use of Assert' as a test method in the XEmacs test suite has never caused any confusion with either C-level asserts, or with the Lisp function
assert'.
- Previous message: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)
- Next message: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]