hunit-users — mailing list for HUnit users

[HUnit-users] monadic HUnit testing

[Shae M. E. <sh...@Sc...>]

in short:

assertEqualM doc resp action = 
    do result <- action
       return $ assertEqual doc resp result

myTestList
    = liftM TestList $ mapM (liftM TestCase)
      [
       assertEqualM "hello xmlrpc" "Hello Haskell" 
       ((remote "http://shapr.homelinux.net:9673/" "pyhello" "Haskell") :: IO [Char])
      ]
h = join $ liftM runTestTT myTestList

main = do c <- h
          putStr $ show c 
          let errs = errors c 
              fails = failures c 
          System.exitWith (codeGet errs fails) 

codeGet errs fails 
 | fails > 0       = ExitFailure 2 
 | errs  > 0       = ExitFailure 1 
 | otherwise       = ExitSuccess 

anyways, I have more demo code along these lines if someone is interested.
-- 
Shae Erisson  -  putStr $ fix("HELLO\n"++)  -  http://www.ScannedInAvian.org/
OSDir: Community building... interesting... what's the secret sauce?
Limi: Irresponsible sleep patterns.
-- Alexander Limi, one of the Plone founders http://osdir.com/Article199.phtml

[HUnit-users] hunit, emacs, one-button unit-testing code

[Shae M. E. <sh...@Sc...>]

I wrote up a description of the one-button unit-testing method I'm using on:
http://www.haskell.org/hawiki/HaskellMode

I'd love to get feedback.

Thanks,
-- 
Shae Matijs Erisson - 2 days older than RFC0226
#haskell on irc.freenode.net - We Put the Funk in Funktion
10 PRINT "HELLO" 20 GOTO 10 ; putStr $ fix ("HELLO\n"++)

[HUnit-users] assertNotEqual versus ~?

[Shae M. E. <sh...@Sc...>]

Hi,
I'm trying to unit test some Parsec code.
I found a case where I want to assertNotEqual, here it is:

"quoted string1" ~: (Right "abc") ~=? (test_run quoted_string "\"abc\""),
"quoted string2" ~: ((Right "abc") /= (test_run quoted_string "\"abc\r\n\"")) 
  ~? "this should not happen"

I'm not sure I'm using ~? correctly. If that's the best way to specify
assertNotEqual, then I'd like to request something like ~/=?

Am I just confused? Would anyone else find ~/=? useful?

thanks,
-- 
Shae Matijs Erisson - 2 days older than RFC0226
#haskell on irc.freenode.net - We Put the Funk in Funktion

Re: [HUnit-users] PyUnit-style progress output

[Dean H. <her...@cs...>]

Shae Matijs Erisson wrote:

> Dean Herington <her...@cs...> writes:
>
> > You had requested test progress output in the style of PyUnit.  I've
> > attached below some code to do that.  As I'm not very familiar with
> > PyUnit, I may not have gotten it just the way you like it, but I'm sure
> > you can "season to taste".
>
> This is great! Thanks much! It works just like I wished for.

Be careful what you wish for!  In fact, the version I posted always reports success
(dots), even in the presence of errors and/or failures.  Moreover, each error and
failure shows as an additional success dot.

A corrected version--well-tested this time, I think--appears below.  Give it a try
while I scrape the egg off my face ...

Dean


module RunTestDots where

import HUnit
import Monad
import IO

-- Runs an HUnit test.  Progress is indicated by writing to standard
-- error a single character for each test case: '.', 'E', or 'F' as
-- the result is "ok", "error", or "failure", respectively.  At the
-- completion of all test cases, the final counts (bracketed by single
-- newlines) are written with `showCounts`.

runTestDots :: Test -> IO Counts
runTestDots t = do
  (counts, final) <- performTest rep (bad 'E') (bad 'F') ' ' t
  rep undefined final
  hPutStrLn stderr ('\n' : showCounts counts)
  return counts
 where
  bad c _ _ _ = return c
  rep _ c = do unless (c == ' ') (do hPutChar stderr c; hFlush stderr)
               return '.'

Re: [HUnit-users] automatic suite statements?

[Shae M. E. <sh...@Sc...>]

Dean Herington <her...@cs...> writes:


> If you mean that you'd like simply to add the top-level definition for a new test
> case and have it included automatically in the set of tests to be run by HUnit, the
> answer is "no".  Haskell doesn't provide the reflection capabilities needed to do
> this.  With HUnit, you must construct the set of tests as a data structure.  (On
> the plus side, it's so much easier to construct test suites as data structures in
> Haskell.)

Rumor on the #haskell irc channel is that Template Haskell will allow for
compile time reflection, I'm looking forward to that.

> But if you find it inconvenient to define a test case and separately add it to a
> test suite, there's no reason you couldn't simply define your new test case
> directly in the data structure representing the suite.  Something like:
> 
>     suite = test [
>       ... test 1 ... ,
>       ... test 2 ... ,
>       ... test 3 ...
>       ]

That's an excellent idea, thanks. This covers what I want.


By the way, if you wish to use Hat 2.00 with HUnit, you need to apply the patch
below because Hat isn't flawless yet.

<paste>

> /home/shae/src/haskell/libraries/THUnitText.hs:64:
>     Variable not in scope: `TPrelude.fnegate'

The problem here is with hat-trans - in the following definition,

    put line pers (-1) = do ...; return (-1)

it has mistakenly interpreted the negative number literal on the left
hand side as a variable binding for negate.  Hence, in the transformed
version of the code, it has used the lambda-bound form `fnegate'
on the right, instead of the real let-bound variable `gnegate'.

Until we can find a fix for hat-trans, here is a workaround for your
application.  Replace the negative numeric literal pattern with another
form, such as a guard.  For instance:

--- HUnitText.lhs	Thu Feb 21 20:21:13 2002
+++ HUnitText.lhs.new	Fri Jul 26 10:43:40 2002
@@ -55,7 +55,8 @@
 > putTextToHandle handle showProgress = PutText put initCnt
 >  where
 >   initCnt = if showProgress then 0 else -1
->   put line pers (-1) = do when pers (hPutStrLn handle line); return (-1)
+>   put line pers  cnt | cnt == (-1)
+>                      = do when pers (hPutStrLn handle line); return (-1)
 >   put line True  cnt = do hPutStrLn handle (erase cnt ++ line); return 0
 >   put line False cnt = do hPutStr handle ('\r' : line); return (length line)
 >     -- The "erasing" strategy with a single '\r' relies on the fact that the

</paste>
-- 
Shae Matijs Erisson - http://www.webwitches.com/~shae/
<radix> shapr: I think you *are* a purist :)
<radix> shapr: it's just that you're morally against unstable software, instead
        of morally against MS, or non-free software, or whatnot.

Re: [HUnit-users] automatic suite statements?

[Dean H. <her...@cs...>]

Shae Matijs Erisson wrote:

> In PyUnit, I'm used to using:
>
> def suite():
>     return unittest.makeSuite(TaskTestCase,'check')
>
> if __name__ == '__main__':
>     unittest.main(defaultTest="suite")
>
> that checks to see if this is running at the top level,
> picks up all the functions that start with "check",
> slurps them together into a suite,
> and executes them.
>
> Is there some way to do that with HUnit?

If you mean that you'd like simply to add the top-level definition for a new test
case and have it included automatically in the set of tests to be run by HUnit, the
answer is "no".  Haskell doesn't provide the reflection capabilities needed to do
this.  With HUnit, you must construct the set of tests as a data structure.  (On
the plus side, it's so much easier to construct test suites as data structures in
Haskell.)

But if you find it inconvenient to define a test case and separately add it to a
test suite, there's no reason you couldn't simply define your new test case
directly in the data structure representing the suite.  Something like:

    suite = test [
      ... test 1 ... ,
      ... test 2 ... ,
      ... test 3 ...
      ]


> so far I've got:
>
> bananaCodecTestList = [labeledTestStringCodec, <insert many tests here>]
> t = runTestTT bananaCodecTestList
>
> So that I can hit C-c C-l in Test_Banana.hs, and then "t" and enter to run all
> of the tests.
>
> That makes it easier to run my tests every minute or so, is there anything
> I can do to make that simpler and easier?

That seems about as simple and easy as possible to me!

Dean

Re: [HUnit-users] PyUnit-style progress output

[Shae M. E. <sh...@Sc...>]

Dean Herington <her...@cs...> writes:

> You had requested test progress output in the style of PyUnit.  I've
> attached below some code to do that.  As I'm not very familiar with
> PyUnit, I may not have gotten it just the way you like it, but I'm sure
> you can "season to taste".

This is great! Thanks much! It works just like I wished for.
-- 
Shae Matijs Erisson - http://www.webwitches.com/~shae/
<radix> shapr: I think you *are* a purist :)
<radix> shapr: it's just that you're morally against unstable software, instead
        of morally against MS, or non-free software, or whatnot.

[HUnit-users] PyUnit-style progress output

[Dean H. <her...@cs...>]

Shae,

You had requested test progress output in the style of PyUnit.  I've
attached below some code to do that.  As I'm not very familiar with
PyUnit, I may not have gotten it just the way you like it, but I'm sure
you can "season to taste".

Sorry for the delay in providing this code.  I just returned from a
relatively long vacation.

Dean


module RunTestDots where

import HUnit
import Monad
import IO

-- Runs an HUnit test.  Progress is indicated by writing to standard
-- error a single character for each test case: '.', 'E', or 'F' as
-- the result is "ok", "error", or "failure", respectively.  At the
-- completion of all test cases, the final counts (bracketed by single
-- newlines) are written with `showCounts`.

runTestDots :: Test -> IO Counts
runTestDots t = do
  (counts, final) <- performTest ok (bad 'E') (bad 'F') True t
  ok undefined final
  hPutStrLn stderr ('\n' : showCounts counts)
  return counts
 where
  ok _ first   = do unless first (put '.'); return False
  bad ch _ _ _ = do               put ch;   return False
  put ch       = do hPutChar stderr '.'; hFlush stderr

[HUnit-users] automatic suite statements?

[Shae M. E. <sh...@Sc...>]

In PyUnit, I'm used to using:

def suite():
    return unittest.makeSuite(TaskTestCase,'check')

if __name__ == '__main__':
    unittest.main(defaultTest="suite")

that checks to see if this is running at the top level,
picks up all the functions that start with "check",
slurps them together into a suite,
and executes them.

Is there some way to do that with HUnit?

so far I've got:

bananaCodecTestList = [labeledTestStringCodec, <insert many tests here>]
t = runTestTT bananaCodecTestList

So that I can hit C-c C-l in Test_Banana.hs, and then "t" and enter to run all
of the tests.

That makes it easier to run my tests every minute or so, is there anything
I can do to make that simpler and easier?

thanks,
-- 
Shae Matijs Erisson - http://www.webwitches.com/~shae/
<radix> shapr: I think you *are* a purist :)
<radix> shapr: it's just that you're morally against unstable software, instead
        of morally against MS, or non-free software, or whatnot.

Re: [HUnit-users] how do you use HUnit?

[Shae M. E. <sh...@Sc...>]

Dean Herington <her...@cs...> writes:

> I'm not sure I understand what you mean by already existing before test.
> That the function must be defined for compilation to succeed?  If that's
> what you mean, I don't think Haskell would differ from any other
> statically typed language, such as Java.  (A dynamically typed language
> might allow execution to begin without all referenced functions being
> defined.  Is this the case with Python?)

Not all dynamically typed languages allow that, but Python does.

> If you're bothered by having to create stubs in Haskell, note that they
> can be more concise than in any other language I know:
> 
>   someFunction = undefined

This is very nifty, it's exactly what I need. Thanks!

> Although I've not had much experience doing Beck-style unit testing, I
> imagine that I do in Haskell pretty much what one does in any language.  I
> write a/some test(s), implying some feature(s) of the interface to the
> unit under construction, then code enough of the implementation for the
> test to pass (which naturally progresses from fixing compilation errors to
> fixing execution errors).  I then repeat as needed to evolve the unit.

Yup, that sounds the same.

Hey, you mentioned that you have PyUnit style output, could I get a copy of
that code?

thanks,
-- 
Shae Matijs Erisson - http://www.webwitches.com/~shae/
<radix> shapr: I think you *are* a purist :)
<radix> shapr: it's just that you're morally against unstable software, instead
        of morally against MS, or non-free software, or whatnot.

Re: [HUnit-users] how do you use HUnit?

[Dean H. <her...@cs...>]

On 14 Jul 2002, Shae Matijs Erisson wrote:

> My primary language has been Python, so learning to think in Haskell is
> difficult.
> I've realized that I don't know how to effectively unit test in a
> language that requires my functions to already exist before I test them.

I'm not sure I understand what you mean by already existing before test.
That the function must be defined for compilation to succeed?  If that's
what you mean, I don't think Haskell would differ from any other
statically typed language, such as Java.  (A dynamically typed language
might allow execution to begin without all referenced functions being
defined.  Is this the case with Python?)

If you're bothered by having to create stubs in Haskell, note that they
can be more concise than in any other language I know:

  someFunction = undefined

> Does anyone have suggestion on how to do unit test first in Haskell?
> Could someone describe their process to me?

Although I've not had much experience doing Beck-style unit testing, I
imagine that I do in Haskell pretty much what one does in any language.  I
write a/some test(s), implying some feature(s) of the interface to the
unit under construction, then code enough of the implementation for the
test to pass (which naturally progresses from fixing compilation errors to
fixing execution errors).  I then repeat as needed to evolve the unit.

> thanks,
> -- 
> Shae Matijs Erisson - http://www.webwitches.com/~shae/

Dean

[HUnit-users] how do you use HUnit?

[Shae M. E. <sh...@Sc...>]

My primary language has been Python, so learning to think in Haskell is
difficult.
I've realized that I don't know how to effectively unit test in a
language that requires my functions to already exist before I test them.

Does anyone have suggestion on how to do unit test first in Haskell?
Could someone describe their process to me?

thanks,
-- 
Shae Matijs Erisson - http://www.webwitches.com/~shae/
<radix> shapr: I think you *are* a purist :)
<radix> shapr: it's just that you're morally against unstable software, instead
        of morally against MS, or non-free software, or whatnot.

[HUnit-users] greetings, anyone awake? one tip, one question

[Shae M. E. <sh...@Sc...>]

I've recently started using HUnit, thought I'd drop by and ask for any tips or
tricks for extra-spiffy testing.

I'm using emacs, ghci, and about as much XP as I can get when I'm developing
open source by myself, for myself.

The only useful tip I can offer is:

> myTestList = TestList [testOne,testTwo]
> t = runTestTT myTestList

At which point I can hit C-c C-l t <enter> to run all of my unit tests.

I haven't learned enough Haskell to figure out exactly which '\r' to replace
with '\n' for correct display inside an emacs comint buffer, any pointers?

thanks,
-- 
Shae Matijs Erisson - http://www.webwitches.com/~shae/
<radix> shapr: I think you *are* a purist :)
<radix> shapr: it's just that you're morally against unstable software, instead
        of morally against MS, or non-free software, or whatnot.