On Thursday, March 21, 2013 13:48:54 Nick Sabalausky wrote: > On Thu, 21 Mar 2013 13:29:35 -0400 > > "Jonathan M Davis" <jmdavisp...@gmx.com> wrote: > > But I don't > > know how you'd automate testing behavior when the exact behavior of > > the range is very much dependent on the range itself. > > I don't think that's true at all. Granted, you can't automate testing > of the range's internal state, but there's a lot about the external > behavior which is very strictly defined: > > Examples: > - Multiple calls to front return the same element. > - Calling popFront and then front returns the next element. > - If range has length, then 'empty' returns true IFF popFront has been > called at least 'myRange.length' times. > - Calling popFront doesn't throw unless range is empty. > - Calling popFront on an empty range throws a RangeError. > - Upon instantiating a new random access range, 'r.front == r[0]', and > then after 'r.popFront()', 'r.front == r[1]', etc. > - 'r.save.front == r.front'. And then call popFront on both ranges, and > 'r1.front == r2.front' is still true. > - Iterating via back/popBack yields the same elements as > front/popFront, but in reverse order. > > And I'm sure there's a whole bunch more. > > If you give a hypothetical generic range-testing tool both an > instantiated range to be tested and an array of all the elements you > expect to be in the range, in the same order, then I'd think all of the > above and more should be testable.
I confess that it pretty much never occurs to me to test most of this stuff. It's always the exact state of the range that I care about, because that has to do with whether the function returns the correct result. But the sort of testing that you're listing here could probably be automated. - Jonathan M Davis