On Wed, Jun 10, 2015 at 4:46 PM, Terry Reedy <tjre...@udel.edu> wrote:
> On 6/10/2015 7:39 PM, Devin Jeanpierre wrote:
>>
>> On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy <tjre...@udel.edu> wrote:
>>>
>>> On 6/10/2015 6:10 PM, Devin Jeanpierre wrote:
>>>
>>>> The problem is that there are two different ways repr might write out
>>>> a dict equal to {'a': 1, 'b': 2}. This can make tests brittle
>
>
> You commented about *tests*
>
>>> Not if one compares objects rather than string representations of
>>> objects.
>>> I am strongly of the view that code and tests should be written to
>>> directly
>>> compare objects as much as possible.
>
>
> I responded about *tests*
>
>> For serialization formats that always output the same string for the
>> same data (like text format protos), there is no practical difference
>> between the two, except that if you're comparing text, you can easily
>> supply a diff to update one to match the other.
>
>
> Serialization is a different issue.Yes, tests of code that uses serialization (caching, RPCs, etc.). I mentioned above a sort of test that divides tests of a client and server along RPC boundaries by providing fake queries and responses, and testing that those are the queries and responses given by the client and server. This way you don't need to actually start the client and server to test them both and their interactions. This is one example, there are other uses, but they go along the same lines. For example, one can also imagine testing that a serialized structure is identical across version changes, so that it's guaranteed to be forwards/backwards compatible. It is not enough to test that the deserialized form is, because it might differ substantially, as long as the communicated serialized structure is the same. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
