1

A library is in src-directory and there is a data definition A. Code related to testing is in test-directory, as suggested in many tutorials, and that includes Serial instance to generate the test cases, see links below:

instance Monad m => Serial m A where ...

cabal test warns that this is an orphan instance. Is this unavoidable or is there an established convention to organize libs, e.g., move serial instance definition to where data A is defined? The latter one somehow feels a bit wrong as it would be nice to keep testing related stuff at test-directory. If this is typical way, in what ways one can avoid exposing the testing related stuff at the public interface? Write 'internal' version of all tested modules (that the public ones and the actual testing program would use)? Something similar was suggested in unit-testing question.

Or does this matter at all? How bad convention it is to leave orphan instances in testing related code?

SmallCheck: Making types instance of typeclass Serial

How to use SmallCheck in Haskell?

Community
  • 1
  • 1
Gspia
  • 809
  • 6
  • 15
  • The practice seems do declare instances in production code, which I dislike too. For Arbitrary or Serial, in my personal projects, I think I can live with orphan instance. But It might be interesting do include theses instance in your production code, because it would be easier for other people to build new tests around your data types. – Jean-Baptiste Potonnier Aug 10 '16 at 11:58
  • 1
    @Jean-BaptistePotonnier, the `Arbitrary` instance used for internal testing may *intentionally* be different from the one you want to expose. It may, for example, want to make sure a balanced tree implementation works even for maximally unbalanced trees. – dfeuer Aug 10 '16 at 14:37
  • @dfeuer I see ! I could imagine do make some performance test too, having different instances for different distributions of data. – Jean-Baptiste Potonnier Aug 10 '16 at 19:27

1 Answers1

1

How bad convention it is to leave orphan instances in testing related code?

Not very. I agree with @Potonnier here. Orphan instances are unpleasant due to Haskell's open-world assumption, but I would argue that your testing executable target is a fairly closed world. We can reasonably expect that nobody will import the modules provided by the test executable package, and that the modules there are the "leaves" of their dependency graph. As long as that much is true, it is hard to imagine a scenario where orphan instances would lead to the worst-case scenario: something like a false positive, where the test passes due to an orphan instance when in fact it should have failed. It is not a binary decision, but I think the cost-benefit analysis here weighs against including the testing libraries as dependencies.

hao
  • 10,138
  • 1
  • 35
  • 50