Reduce code duplication in testsuite

[snowleopard]

Reduce code duplication in testsuite

[anfelor]

Have you looked into doctest? I think it would go a long way towards reducing code duplication.

[snowleopard]

@anfelor Thanks for the pointer! I haven't tried it but it looks promising.

It will likely not be able to handle all examples, as some of them use function equality. We need a proof-of-concept implementation.

[nobrakal]

So I tried with doctest. Took some time to set up (the need to hide some of Prelude, etc), but I came to a partial implementation of tests of Algebra.Graph.

You can see the (very very partial, in fact just for the data definition and the first function) results here: nobrakal@6a65eb1

With a "clever" setup (where I define the (+) and (*) operators, and copied/pasted the Arbitrary instance of Graph Int), doctest detect and test everything like:

-- prop>       (x + y) == (y + x)
-- prop>   x + (y + z) == (x + y) + z

and

-- >>> isEmpty empty
-- True

So the pros:

• It definitely reduce code duplication :)

Cons:

• The $setup part is not beautiful at all, but I think it could be improved
• About haddock, the doc will be less pretty, because haddock render prop> line-by-line. I also think you cannot "reference" a function in a prop> (make a link form its name to its definition)

Question:

• Not sure how to handle things like

isEmpty empty     == True

prop> make a pretty output but is not very made for it, but the syntax

-- >>> isEmpty empty
-- True

render not really great in haddock.

What do you think ?

[snowleopard]

@nobrakal Thanks for the experiment! These examples look good, but I think there will be many cases where things will start breaking, e.g. there are function comparisons hasVertex x . vertices == elem x which will have to be converted to the form hasVertex x (vertices xs) == elem x xs, which is probably fine for this example, but there may be others :-)

I don't like that we lose references to functions. I think these references make examples very convenient and encourage the exploration of the library.

isEmpty empty == True

I don't understand: what's wrong with this property? Why can't you use it as is?

[nobrakal]

but there may be others :-)

Mmhhh, will need to implement more of the file to see if there is really a problem.

. I think these references make examples very convenient and encourage the exploration of the library.

I agree with you about the reference for functions, I have opened an issue here: haskell/haddock#827 to see what can be done.

I don't understand: what's wrong with this property? Why can't you use it as is?

I can totally use prop> isEmpty empty == True, but doctest, and haddock, view this not as a property but as an example, and thus the "standard way" is to use

-- >>> isEmpty empty
-- True

Which one do you prefer ? This is I think only a graphic issue, but is important when speaking of documentation...

[snowleopard]

I have opened an issue here: haskell/haddock#827 to see what can be done.

Awesome, thanks!

Which one do you prefer ?

I prefer to stick to properties throughout the module -- for consistency. So, let's use isEmpty empty == True.

[snowleopard]

This looks like an awesome library we should give a try: https://hackage.haskell.org/package/hedgehog-classes-0.1.1.0/docs/Hedgehog-Classes.html