On Thursday, March 21, 2013 13:08:58 Nick Sabalausky wrote: > Suppose you create a range: struct MyRange{...} > > Now you have to unittest it. And there's a lot of ways a range > implementation can go wrong. There's a fair amount of things to test. > And they all, ideally, need to be done for *every* range type created. > > But, ranges are all supposed to conform to a standard interface with > standardized semantics. So can't most of this testing be generalized > into a generic InputRangeTester, RandomAccessRageTester, etc? All you'd > do is feed it an array of elements to test with, and, in theory, it > should be able to unittest the range's semantics for conformance. > > Obviously it couldn't guarantee 100% conformance, because no unittest > can do that, but it seems reasonable that it could be just as good as a > well-designed set of hand-written tests. > > I think this would be an enormously useful thing to have in Phobos. Can > any Phobos/range gurus say fur sure how feasible this is? Does Phobos > perhaps already do something similar internally that could just be > generalized? > > (This message has been brought to you by three random access ranges I > just created but really, really don't feel like unittesting ;) )
Hmmm. I've been working on stuff which makes creating ranges to test range- based functions easier, but I've never thought about creating something to test conformance. If I need something like that I just use static asserts to test isInputRange, isForwardRange, etc. and make sure that each of the ones that are supposed to pass for that range do and that those that aren't supposed to pass don't. All that that's going to test though is the API, not behavior. 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. In most cases though, you end up with a new range type, because it's being returned from a range-based function, in which case, simply unit testing the function with a variety of range types generally takes care of it, and those aren't particularly automatable, because what the tests need to test depends entirely on what the function is supposed to do. - Jonathan M Davis