On 3/14/2012 4:53 PM, Herman wrote:
I followed the rule because it was a very good advice. For example,
def test_plus_1Plus1_2(self):
Suppose you want to test that a function call returns a particular
300-char multiline string?
If this test fails, you immediately know that it's testing the "plus"
method, with 1 and 1 as the arguments, and expect to return 2.
If you use unittest and the right assert method, the message will say
more than pass/fail. I believe .AssertEqual(a,b, 'optional message')
will say that a is not equal to b, and print the optional message.
"In addition, if first and second are the exact same type and one of
list, tuple, dict, set, frozenset or str or any type that a subclass
registers with addTypeEqualityFunc() the type-specific equality function
will be called in order to generate a more useful default error message
(see also the list of type-specific methods)."
For instance
"assertMultiLineEqual(first, second, msg=None)
Test that the multiline string first is equal to the string second. When
not equal a diff of the two strings highlighting the differences will be
included in the error message. This method is used by default when
comparing strings with assertEqual()."
Sticking this rule also means your test cases are small enough,
To me, it makes them too small. I think a test of addition should have
multiple input-output pairs. Besides that, a single test output object
may need to pass multiple conditions to pass. Putting them all in a
single large conjuction would obscure which is not passing.
However, anything is better than no tests.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
