Feasible Idea?: Range Tester

[H. S. Teoh]

On Thu, Mar 21, 2013 at 01:48:54PM -0400, Nick Sabalausky wrote:
> 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.

This is easy to test.


> - Calling popFront and then front returns the next element.

How do you know if something is the "next element"? What if the range is
repeat(1)?


> - If range has length, then 'empty' returns true IFF popFront has been
>   called at least 'myRange.length' times.

This should also be easy to test. But it requires the ability to
instantiate the range with some given number of elements. So you still
need a range-specific function to create the range in the first place.


> - Calling popFront doesn't throw unless range is empty.

Should be easy to check.


> - Calling popFront on an empty range throws a RangeError.

Is this part of the official requirement on ranges? I've been guilty of
writing ranges whose popFront are no-ops when the range is empty (simply
because for some ranges, it's a pain to explicitly check for this and
throw, when the popFront computation doesn't actually assume anything
about emptiness).


> - Upon instantiating a new random access range, 'r.front == r[0]', and
>   then after 'r.popFront()', 'r.front == r[1]', etc.

This should be relatively easy to check.


> - 'r.save.front == r.front'. And then call popFront on both ranges, and
>   'r1.front == r2.front' is still true.

Should be easy to check too.

I was gonna say that you'd have to watch out for RNGs, as popFront on an
RNG that bases its output on, say, random environmental factors, will
break this rule; but on second thought, in this case .save is invalid on
such ranges (they can only be input ranges) so this check *should* fail.


> - Iterating via back/popBack yields the same elements as
>   front/popFront, but in reverse order.

Doesn't work on infinite ranges. :) (You *can* have infinite ranges with
two ends. There's no good reason to do that, of course, because they are
effectively just two infinite forward ranges stuck together at their
infinite ends, which is kinda pointless, but in theory, this *can*
happen.)


> 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.

This wouldn't work on infinite ranges. :) But you could at least test
some initial segment of an infinite range, I suppose, so this shouldn't
be too big of an issue.


T

-- 
Amateurs built the Ark; professionals built the Titanic.