Feasible Idea?: Range Tester

[Dmitry Olshansky]

21-Mar-2013 21:48, 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.
>

Indeed there is a host of invariants that must hold for any range of 
certain kind. I'd say this along with other stuff should go into 
std.test or std.testing (or package within) etc.

-- 
Dmitry Olshansky