HUnit false-positive stumper

While working on a project of mine recently I realized that a particular HUnit test should have been failing. After paring things down, I came up with this shocker: test_perhaps.hs:
module Main where import Test.HUnit main = runTestTT $ TestList [ True ~=? True , False ~=? True , TestCase $ assertEqual "both true" True True , TestCase $ assertEqual "false true" False True ]
$ cabal-dev install ... $ ./cabal-dev/bin/test_perhaps.hs ### Failure in: 3 false true expected: False but got: True Cases: 4 Tried: 4 Errors: 0 Failures: 1 The shock here is that there was only one failure, whereas the "False ~=? True" should have failed. Environment: MacOS 10.5.8 (Leopard) GHC 6.12.3 cabal-dev 0.7.4.1 Cabal 1.10.1.0 HUnit 1.2.2.3 I even tried removing the dist and cabal-dev directories and reattempting but got the same results. I tried the same test in a different environment (Linux PC w/GHC 7.0.2, all other elements the same) and got correct results: $ ./cabal-dev/bin/test_perhaps ### Failure in: 1 expected: False but got: True ### Failure in: 3 false true expected: False but got: True Cases: 4 Tried: 4 Errors: 0 Failures: 2 $ I realize it's very difficult to debug someone's setup remotely, but I have to confess I'm really stumped at this point. The input program is pretty straightforward, and I *have* gotten test failures in the past on the Mac. I did do a "cabal update" the other day after being informed that my hackage file was getting old, but HUnit hasn't changed in months. I even tried unpacking HUnit and reducing the (non-)failing test case by using the definitions of the elements:
module Main where
import Control.Monad (unless) import Test.HUnit
main = runTestTT $ TestList [ True ~=? True , False ~=? True , TestCase $ assertEqual "both true" True True , TestCase $ assertEqual "false true" False True , TestCase $ assertEqual "fa" False True , TestCase $ assertEqual "f" False True , TestCase $ (False @?= True) , TestCase $ unless (False == True) (assertFailure "f") ]
The results are very strange: $ ./cabal-dev/bin/test_perhaps ### Failure in: 3 false true expected: False but got: True ### Failure in: 4 fa expected: False but got: True ### Failure in: 7 f Cases: 8 Tried: 8 Errors: 0 Failures: 3 $ The assertEqual form doesn't fail as it should if the label is a single character (test 5), but in its fully expanded form (test 7) it will fail. Huh?! At this point I'm thoroughly confused. I'm using 6.12.3 on the Mac because I don't have the newer MacOS release for which there's a Haskell Platform release and I haven't wanted to build GHC by hand. I wouldn't expect 6.12.3 to have issues like this, but I wouldn't expect issues like this anywhere. If anyone has any suggestions (other than upgrading to GHC 7.x) I'll be most appreciative. -- -KQ

On 6 June 2011 02:34, KQ
The shock here is that there was only one failure, whereas the "False ~=? True" should have failed.
I'm not sure, but at a glance it looks you might have the usual problem where compiling your test with optimisations means that GHC optimises away the test failure. This is a known problem. If you compile with -fno-state-hack (or -O0) it should work. Max

On 06/06/2011 10:23, Max Bolingbroke wrote:
On 6 June 2011 02:34, KQ
wrote: The shock here is that there was only one failure, whereas the "False ~=? True" should have failed.
I'm not sure, but at a glance it looks you might have the usual problem where compiling your test with optimisations means that GHC optimises away the test failure. This is a known problem. If you compile with -fno-state-hack (or -O0) it should work.
Can anyone expand on this? It seems odd to me that, an optimisation that causes some programs to behave incorrectly is switched on as part of the optimisation suites. Especially as there's no warning in the manual (or at least, not under http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.htm... which seems like the obvious place) I found some references to -fno-state-hack being required when compiling without occasionally causes bad performance, and also to prevent unsafePerformIOs being optimised away, but these seem a lot less bad. (Performance changes aren't as bad as correctness, and unsafePerformIO is known to be, well unsafe). I also found quite a few references to how beneficial this optimisation is to IO code, but I wonder if program correctness is a price worth paying. Or is this bad behaviour due to HUnit doing something unsafe? Regards, Jim

On 6 June 2011 16:18, Jimbo Massive
Or is this bad behaviour due to HUnit doing something unsafe?
I think it may be related to this bug: http://hackage.haskell.org/trac/ghc/ticket/5129 The suggested fix is to change HUnit to define assertFailure with throwIO, but the latest source code still uses throw: http://hackage.haskell.org/trac/ghc/ticket/5129 So this could very well be a HUnit bug. Max

On 6 June 2011 16:43, Max Bolingbroke
The suggested fix is to change HUnit to define assertFailure with throwIO, but the latest source code still uses throw:
Err, I mean http://hackage.haskell.org/packages/archive/HUnit/latest/doc/html/src/Test-H...

That sounds very applicable to my issue (and unfortunately my googling missed
this, ergo my consult of haskell-cafe uberwissenmensch). When I again have
access to the aforementioned Mac this evening I'll try both disabling
optimizations and a tweaked HUnit to see if that resolves the problem and
report back then.
-KQ
Quoting Max Bolingbroke
On 6 June 2011 16:18, Jimbo Massive
wrote: Or is this bad behaviour due to HUnit doing something unsafe?
I think it may be related to this bug: http://hackage.haskell.org/trac/ghc/ticket/5129
The suggested fix is to change HUnit to define assertFailure with throwIO, but the latest source code still uses throw:
http://hackage.haskell.org/trac/ghc/ticket/5129
So this could very well be a HUnit bug.
Max
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

Didn't get to this last night but I've just now confirmed this. With a normal build (defaulting to -O) the test code below generates only 3 failures (MacOS Leopard w/GHC 6.12.3 and HUnit 1.2.2.3). When using -O0 or by changing assertFailure in Test.HUnit.Lang (line 81) to use E.throwIO instead of E.throw I get the expected 6 failures. This is very reproducible for me. I can use -O0 for my tests, but it would be great if HUnit were updated to use the throwIO call (cc'ing Richard Giraud accordingly). Thanks! -KQ
module Main where
import Control.Monad (unless) import Test.HUnit
main = runTestTT $ TestList [ True ~=? True , False ~=? True , TestCase $ assertEqual "both true" True True , TestCase $ assertEqual "false true" False True , TestCase $ assertEqual "fa" False True , TestCase $ assertEqual "f" False True , TestCase $ (False @?= True) , TestCase $ unless (False == True) (assertFailure "f") ]
On Mon, 06 Jun 2011 09:00:07 -0700,
That sounds very applicable to my issue (and unfortunately my googling missed this, ergo my consult of haskell-cafe uberwissenmensch). When I again have access to the aforementioned Mac this evening I'll try both disabling optimizations and a tweaked HUnit to see if that resolves the problem and report back then.
-KQ
Quoting Max Bolingbroke
: On 6 June 2011 16:18, Jimbo Massive
wrote: Or is this bad behaviour due to HUnit doing something unsafe?
I think it may be related to this bug: http://hackage.haskell.org/trac/ghc/ticket/5129
The suggested fix is to change HUnit to define assertFailure with throwIO, but the latest source code still uses throw:
http://hackage.haskell.org/trac/ghc/ticket/5129
So this could very well be a HUnit bug.
Max
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- -KQ
participants (4)
-
Jimbo Massive
-
KQ
-
Max Bolingbroke
-
quick@sparq.org