haskell - Tasty Hunit testing of a parsec parser? -


i need set test suit lets me determine whether changes make in parsec parser not break else down line.

i using tasty unit tests this, , have:

simplelabels :: testtree simplelabels = testgroup "simple label searches"     [ testcase "list comparison (same length)" $ -- test make sure @?= works should       [1, 2, 3] `compare` [1,2,2] @?= lt       ,        testcase "phonetic = " $          parse umequery "source" "phonetic = " @?= right ( labelinlabeltype "phonetic" ["a"] "=")       ] 

now, stream parsed correctly parser when run in repl:

> parse umequery "something"  (pack  "phonetic = ") right (labelinlabeltype "phonetic" ["a"] "=") 

this should be, , therefore set in test above.

now, test suite not build @ all, giving error:

testqueryparser.hs:29:55:     no instance (eq parseerror) arising use of ‘@?=’     in second argument of ‘($)’, namely       ‘parse umequery "ume query : " "phonetic = "        @?= right (labelinlabeltype "phonetic" ["a"] "=")’     in expression:       testcase "phonetic = "       $ parse umequery "ume query : " "phonetic = "         @?= right (labelinlabeltype "phonetic" ["a"] "=")     in second argument of ‘testgroup’, namely       ‘[testcase "list comparison (same length)"         $ [1, 2, ....] `compare` [1, 2, ....] @?= lt,         testcase "phonetic = "         $ parse umequery "ume query : " "phonetic = "           @?= right (labelinlabeltype "phonetic" ["a"] "=")]’ 

how come need this, considering fact success/correct parsing should result in right a value?

what best way set unit test parsec parser?

thank helpful comments.

indeed, pointed out @user2407038, better handling of error message required.

simplelabels :: testtree simplelabels = testgroup "simple label searches"     [     testcase "equality matching simple label" $ let          res = case (parse umequery "source" "phonetic = ") of             right ->             left -> error "something"     in res @?=  labelinlabeltype "phonetic" ["a"] "="     ] 

works. error message in example above not optimal, suitable sake of current example.


Comments