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.