Reduce code duplication in testsuite

[snowleopard]

There is a lot of code duplication in the testsuite currently. For example, see this commit: https://github.com/snowleopard/alga/commit/fc2854de76e7e05be5fd09c362750d6db9a05502.

It should be possible to get rid of most duplication by defining generic testsuites like this one.

There is also duplication in the documentation (see the same commit example above), but I'm not sure if it's possible to do anything about it.

[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: https://github.com/nobrakal/alga/commit/6a65eb19ba4a5fb7934f16e7e66a0bfa4b429693

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: https://github.com/haskell/haddock/issues/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