Re: [Pyunit-interest] comments on PyUnit

[Graham H. <gr...@ly...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Patrick K. O'Brien" <po...@or...> writes:

> Were you honestly able to maintain a straight face while you wrote this? Why
> would we write tests that we expected to fail? We expect all the tests to
> succeed, unless the code is wrong. That is the whole premise behind the unit
> testing framework. Take a look at these method descriptions taken from
> http://www.python.org/doc/current/lib/testcase-objects.html and try to think
> of a good name for each method:

On the contrary, often I test that things fail in the correct manner:
for example, `assert not cgi.isValid ()' from my validation suite.
`self.failIf (cgi.isValid ())' would be a considerable improvement,
but in a different test `self._assert (cgi.isValid ())' is just fine.
If anything is to be removed I would argue assert* and fail* methods
with the word `not' in them should die, because it makes the logic
even more circuitous than necessary.  But I don't use them and I don't
particularly begrudge others the use of them.

>     Test that first and second are equal. (sounds like testEqual to me)
> 
>     Test that first and second are not equal. (sounds like testNotEqual to
> me)
> 
>     Test that an exception is raised. (sounds like testException or
> testRaises to me)

Having worked with PyUnit for quite some time now, I cannot agree.
testEqual communicates nothing; am I testing whether they *are* equal?
You say the answer is obviously yes, but test alone is an empty verb.
`Test', in the absence of context, means `to subject to a test', and
connotes nothing about the direction of the desired result!

The assert* and fail* are much better for this.  If you know what the
word assert means, it is very easy to see which direction assertEqual
and failIfEqual go.  testEqual isn't even good English--it should be
testEquality at the very least, and then testInequality--and is silent
regardless on whether the test should succeed or fail.

You assert that it is obvious that the test should succeed because you
assert that all tests must succeed, but the logic in this is
unconvincing to me.

> I can't think of any word that is less ambiguous in this context. Who cares
> what action is to be taken? We just want to test certain conditions and
> raise a red flag if anything breaks. Some of those conditions happen to fit
> into a common pattern so we have specific methods for those - we want to
> test for equality, inequality and the raising of exceptions. Then we have a
> blanket test that allows the user to define their own condition. Finally, we
> want to test for the inverse of some condition.

I care what action is to be taken.  I want it to be obvious that the
test will *fail* if the two arguments are equal, that the test will
*fail* if the exception is not raised.

<snip rest>
- -- 
Graham Hughes <gr...@ly...>
PGP fingerprint: 1F1D 0027 B835 E114 3F5B  2C7C 64D1 83A0 C5C7 312A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard <http://www.gnupg.org/>

iD8DBQE7QnGlZNGDoMXHMSoRAnzrAKDH+ngj5Sr9W1hP+und6PQ2BgH/AwCgqAEb
GQYz3/9411CQ/6+tPxzFK0s=
=xm5Y
-----END PGP SIGNATURE-----