On 7/1/05, Michael G Schwern <[EMAIL PROTECTED]> wrote: > On Fri, Jul 01, 2005 at 10:28:29AM -0700, Ovid wrote: > > So, just for the sake of argument, imagine I write a class where I > > periodically returns array refs to the user. I do this by building > > them every time they're called. Later, I realize that my methods are > > deterministic so I start caching results and returning them instead of > > rebuilding the array each time. I'm expecting my test suite to still > > continue working but under this proposed idea, it could be a nightmare > > for me to debug. Heck, when I print out the arrays with Data::Dumper, > > I'll see the same values and be mystified why they're not equivalent. > > Another nail driven home.
See my pending reply to Ovid. In short DD will produce different dumps. > > Ovid's given an example of how this violates encapsulation making it > difficult to write black box tests which do not make assumptions about the > implementation. Under Yves' suggestion if you replace a set of identical > objects with a singleton your tests fail. This is wrong since the external > interface did not change. This is consistent with is_deeply()'s positions > on overloading, tying and blessing. > > "wrong" is relative because where I'm drawing the black box is a choice. > Yves would have it be a bit deeper so the change from copied object to > singleton becomes apparent. And maybe you do want that, if the objects > are alterable then there could be an interface change as now altering > one alters the other... or maybe it doesn't. Maybe its COW. Well as you said you are drawing the black box in an arbitrary place. The problem i have with this position is that the opposite scenario seems to me to be equally likely. The procedure should return N isomorphs and breaks such that it returns N copies of the same object. Nothing breaks. The tester should know what type of check they want. And if they are using is_deeply() and it fails they should realize why and know what to do to fix it. Having said that im resigned now to this behaviour not changing. Mores the pity. > > Point is the line between "internal" and "external" expectations has to be > drawn somewhere. I've drawn it a bit further out from true equivalency > to ignore some differences which are usually inconsequential. Yves would > like it pushed back to test true equivalency. The two positions cannot > co-exist in the same function. One is not right nor wrong, they're just > different functions. I agree with you here totally. I just think they can happily coexist in Test::More using mostly the same code without too much code change. Its too bad that is_deeply() was the name chosen for the weaker behaviour and I think the docs need to change to reflect that this can be misleading. It should be absolutely clear from the documentation that the routine is not checking if the objects are deepcopies of each other. It should probably include the sentence "ignores references to composite objects unless they are non empty and different". I particularly object to the wording "it does a deep comparison walking each data structure to see if they are equivalent. If the two structures are different, it will display the place where they start differing." cheers yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
