On Fri, Dec 8, 2017 at 10:10 AM, Erik Bray <erik.m.b...@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 12:56 AM, Michael Orlitzky <mich...@orlitzky.com>
> wrote:
>> On 12/06/2017 09:49 AM, Erik Bray wrote:
>>>
>>> Did anyone ever think up a better solution to this?
>>>
>>
>> Whatever you do, you wind up with a big pile of dict output in the
>> middle of your test case. So (where possible) you might as well use that
>> space to define a new dict containing the expected value. For example,
>>
>> >>> actual = some_computation()
>> >>> expected = { 1: "one",
>> ... 2: "two",
>> ... 9: "nine" }
>> >>> actual == expected
>> True
>>
>> That's harder to do when the dict is buried in some other data
>> structure, but maybe we shouldn't be testing the exact string
>> representation of some big conglomerate in the first place -- do we
>> actually care what it is? Instead, we should test only what we care about.
>>
>> Regardless, I don't think the framework should make it look like you can
>> rely on dicts being sorted when you can't. Users should be able to run
>> the EXAMPLES and see what we say they'll see.
>
> That is a good thing and a bad thing about so many of the tests
> doubling as "examples" in the documentation (especially for 'public'
> methods to the extent that there is such a thing). You want them to
> actually function nicely as examples of how a user should use an
> interface and what a user should expect to see. Going into
> contortions in order to make it function reliably as a test can be at
> odds with that.
>
> If we're talking one dict it's not much of a problem. The main
> problem seems to be with more complex objects that contain dicts
> nested in their reprs. And you do sometimes want to test the repr
> string itself too (that, however, could be in the form of a TEST not
> an EXAMPLE).
Another workaround that's so obvious I smacked myself on the head is
that for many cases, particularly objects that have a small dict in
their representation, is to simply change the __repr__ so that its
dict is always displayed sorted. If the order doesn't matter anyways
that it doesn't hurt to impose an order at least for the __repr__. I
doubt there are many cases where this should have any performance
impact either.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
