[Haskell-cafe] ANN: rematch, an library for composable assertions with human readable failure messages

Roman Cheplyaka roma at ro-che.info
Tue Apr 16 16:09:41 CEST 2013

Hi Tom,

This is a neat idea! I'd like to use something like this in smallcheck
and test-framework-golden.

The main obstacle to that is that your package depends on QuickCheck and
HUnit, and every package using rematch would transitively depend on
them, too. This has little sense, especially for smallcheck which is in
some sense a replacement for QuickCheck.

The alternative is either to put HUnit and QuickCheck interfaces in
the separate packages, or try to get them accepted into the HUnit and
QuickCheck directly.

Below are some more suggestions regarding the package:

1. You need to escape single and double quotes in the haddock
   documentation; otherwise they'll be turned into (bad) links.

2. Your 'join' function is a special case of 'intercalate' from

3. The "Control" namespace doesn't quite match the purpose of your
   modules, since they are not about control flow. Perhaps "Test"?

I also wonder whether there is a more principled approach to such an API — 
say, based on applicative functors.


* Tom Crayford <tcrayford at gmail.com> [2013-04-16 10:17:48+0100]
> I kept on running into this thing where I was calling error in quickcheck
> to get good error messages about the things I was comparing. In Java land,
> this stuff is handled by Hamcrest: a library for composable assertions with
> good error messages. This library is basically a port of hamcrest's core
> api, but I've been very pleased with how it turned out.
> I've been using this in tests for production code for a month or so now,
> and I'm very pleased with it.
> Running a matcher (in this example in an hunit test) looks like this:
> expect [1] (is [1])
>  The core API is very simple:
> data Matcher a = Matcher {
>     match :: a -> Bool
>   -- ^ A function that returns True if the matcher should pass, False if it
> should fail
>   , description :: String
>   -- ^ A description of the matcher (usually of its success conditions)
>   , describeMismatch :: a -> String
>   -- ^ A description to be shown if the match fails.
>   }
> This means you can add/write your own matchers happily, which occasionally
> means you can write *very* nice test code (here's an example of using a
> custom matcher for checking the state of an "issue" in a hypothetical issue
> tracking app):
> expect latestIssue (hasState Resolved)
> -- I removed the supporting code to make this assertion actually run,
> -- this email is already pretty long.
> There are numerous matchers (and functions for creating matchers) in the
> rematch library, including some composition functions that provide good
> failure messages.
> There are some shims to hook rematch into the common haskell test
> frameworks (specifically hunit and quickcheck).
> The two libraries are up on hackage:
> http://hackage.haskell.org/package/rematch
> http://hackage.haskell.org/package/rematch-text
> The code is all up on github:
> http://github.com/tcrayford/rematch
> I get rather frustrated when my tests give bad failure explanations, and
> using rematch goes a long way to fix that.
> Lastly, rematch is pretty isolated from test frameworks/etc, with a very
> small and easy to understand surface api. Hopefully it'll help with the
> thing I've seen in other languages (cough ruby cough) with every test
> framework reinventing this idea, and not all frameworks having all the
> matchers I want to use.
> Let me know if you have any feedback/thoughts
> Tom

> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list