Feasible Idea?: Range Tester

Jonathan M Davis jmdavisProg at gmx.com
Thu Mar 21 11:20:24 PDT 2013


On Thursday, March 21, 2013 13:48:54 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.
> - 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


More information about the Digitalmars-d mailing list