QuickCheck properties: export or not?
I was recently sent a patch for my Ranged Sets library which exported all the QuickCheck properties. I'd left them unexported on the grounds that they clutter up the documentation (although simplified versions are included in the documentation) and you can easily run them with the standard "quickcheck" script. The contributor, gwern0@gmail.com suggested an explicit test harness instead. I'm not unduly bothered one way or the other, but I thought I'd ask the community: what is the best practice here? Paul.
paul:
I was recently sent a patch for my Ranged Sets library which exported all the QuickCheck properties. I'd left them unexported on the grounds that they clutter up the documentation (although simplified versions are included in the documentation) and you can easily run them with the standard "quickcheck" script. The contributor, gwern0@gmail.com suggested an explicit test harness instead.
I'm not unduly bothered one way or the other, but I thought I'd ask the community: what is the best practice here?
Most libs seem to include an external Properties.hs or similar file. The only tension there is how much do you need to test thoroughly. You might still end up exporting more than you wish to. -- Don
Hi
standard "quickcheck" script. The contributor, gwern0@gmail.com suggested an explicit test harness instead.
Unless you have a test harness (ideally through Cabal), the properties will go out of sync, and you'll forget to run them. Tests are good, they should be able to be invoked as standard. Every time I've *not* done a test harness, and then relied on manually remembering things or putting them in the documentation, it has gone wrong very quickly! Thanks Neil
ndmitchell:
Hi
standard "quickcheck" script. The contributor, gwern0@gmail.com suggested an explicit test harness instead.
Unless you have a test harness (ideally through Cabal), the properties will go out of sync, and you'll forget to run them. Tests are good, they should be able to be invoked as standard. Every time I've *not* done a test harness, and then relied on manually remembering things or putting them in the documentation, it has gone wrong very quickly!
I usually have a main = runTests file, and then use darcs to ensure the tests are up to date: $ cat _darcs/prefs/prefs test ghc -no-recomp -Onot -fasm -itests tests/Unit.hs --make -odir /tmp && tests/Unit darcs will run the testsuite, and it needs to pass, before a commit will be accepted. We do a similar thing for xmonad. The test command to run on every commit can be set via, darcs setpref test "my test command" -- Don
I think that type classes with nontrivial requirements should export QuickCheck properties that test those requirements. For example, the Data.Monoid module (http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html) could export properties that check the monoid laws (for an Arbitrary Monoid with Eq). That would serve as a formal specification of the requirements, and allow any user to check that their implementation is right. -- I'm doing Science and I'm still alive.
participants (4)
-
David Benbennick -
Don Stewart -
Neil Mitchell -
Paul Johnson