[Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

[Ron Adam]

On 12/24/2010 02:03 PM, Raymond Hettinger wrote:
>
> On Dec 24, 2010, at 10:56 AM, Terry Reedy wrote:
>
>> On 12/24/2010 11:09 AM, Michael Foord wrote:
>>> On 22/12/2010 02:26, Terry Reedy wrote:
>>>> On 12/21/2010 7:17 AM, Michael Foord wrote:
>>>>
>>>> My first priority is that doc and code match.
>>>> Close second is consistency (hence, ease of learning and use) between
>>>> various AssertXs.
>>>>
>>>>> Symmetrical diffs (element in first not in second, element in second not
>>>>> in first) solves the problem without imposing an order on the arguments.
>>>>
>>>> Where applicable, I prefer this as unambiguous output headings.
>>>>
>>> Could you explain what you mean?
>>

>> I was referring back to an output example symmetric diff that was
>> clipped somewhere along the way:
>>
>> In x not in y: ... In y not in x: ...
>>
>> rather than just using -,+ prefixes which are not necessarily
>> self-explanatory. 'Not applicable' would refer to output from difflib
>> which necessarily is ordered.

> FWIW, I think + and - prefixes are much better for diffs that some
> made-up verbiage.  People are used to seeing diffs with + and -.
> Anything else will be so contrived that it's net effect will be to make
> the output confusing and hard to interpret.

Agree.


> If you want, add two lines of explanation before the diff: + means "in
> x, not in y" -  means "in y, not it x"
>
> The notion  of "making symmetric" can easily get carried too far, which
> a corresponding loss of useability.

I agree with this also.

I don't understand the effort to make the tests be symmetric when many of 
the tests are non-symmetric.  (see list below)

I think the terms expected and actual are fine and help more than they 
hurt.  I think of these as "actual result" and "expected result". A clearer 
terminology might be "expr" and "expected_result".

Where a tests can be used *as if* they are symmetric, but the diff context 
is reversed, I think that that is ok.  It just needs a entry in the docs 
that says that will happen if you do it. That won't break tests already 
written.

Also notice (in the list below) that the use of 'a' and 'b' do not indicate 
a test is symmetric, but instead are used where they are *not-symmetric*. 
First and second could be used for those, but I think 'a' and 'b' have less 
mental luggage when it comes to visually seeing the meaning of the method 
signature in those cases.

Tests where the order is not important usually use numbered but like 
arguments, such as "expr1" and "expr2" or "list1" and "list2".  This makes 
sense to me.  "obj1" and "obj2" are just two objects.

The terms "x in y" and "x not in y" look like what you should get from 
containment or regex asserts.

I guess what I'm try to say is think of the whole picture when trying to 
make improvements like these, an idea that works for one or two things may 
not scale well.

Cheers,
    Ron


Non-symmetric assert methods.

assertDictContainsSubset(self, expected, actual, msg=None)
assertFalse(self, expr, msg=None)
assertGreater(self, a, b, msg=None)
assertGreaterEqual(self, a, b, msg=None)
assertIn(self, member, container, msg=None)
assertIsInstance(self, obj, cls, msg=None)
assertIsNone(self, obj, msg=None)
assertIsNotNone(self, obj, msg=None)
assertLess(self, a, b, msg=None)
assertLessEqual(self, a, b, msg=None)
assertNotIn(self, member, container, msg=None)
assertIsInstance(self, obj, cls, msg=None)
assertIsNone(self, obj, msg=None)
assertIsNotNone(self, obj, msg=None)
assertNotIn(self, member, container, msg=None)
assertNotIsInstance(self, obj, cls, msg=None)
assertRegex(self, text, expected_regex, msg=None)
assertNotRegexMatches(self, text, unexpected_regex, msg=None)
assertRaises(self, excClass, callableObj=None, *args, **kwargs)
assertRaisesRegex(self, expected_exception, expected_regex,
                    callable_obj=None, *args, **kwargs)
assertRegex(self, text, expected_regex, msg=None)
assertTrue(self, expr, msg=None)
assertWarns(self, expected_warning, callable_obj=None, *args, **kwargs)
assertWarnsRegex(self, expected_warning, expected_regex,
                   callable_obj=None, *args, **kwargs)