Feasible Idea?: Range Tester

[Nick Sabalausky]

On Thu, 21 Mar 2013 13:29:35 -0400
"Jonathan M Davis" <jmdavisProg at 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.