[Haskell-beginners] testing and the culture of Haskell

Tue Jan 19 17:36:57 EST 2010

Michael,

 > A friend asked me about Test-Driven Development (TDD) within the FP
 > community.

My brother is a TDD (Test-Driven Development) guru but not a Haskeller, 
and I'm a Haskeller, and I've thought a lot about this question and 
asked around in the community.  My brother and I are always attempting 
to brainwash each other.  It's been quite effective so I essentially 
agree with TDD.  Here's my 2c worth on your questions:

 > Q: Is TDD advocated the Haskell community? Is it controversial? Is it
 > even on the radar?

I've never heard of anyone advocating TDD in the Haskell community.  It 
isn't controversial - it's on the radar for a minority, presumably in 
proportion to how much of their heads are in the mainstream community 
vs. the functional community.  So the functional community doesn't 
generally talk about TDD.

 > Q: If TDD is not advocated: why? Is there something about the Zen of
 > Haskell development that
 > is an impedance mismatch with TDD?

After much pondering, and with the proviso that everything is In My 
Humble Opinion, I believe there are some very sound technical reason why 
TDD doesn't quite work for Haskell.  TDD is really intended to catch two 
kinds of errors:  Programming mistakes, and wrong logic.  TDD proponents 
say "test logic only", but as a happy side effect they're catching a lot 
of programming mistakes too, and this adds significantly to the value of 
TDD.

Another reason behind TDD is that if your code is testable, then it 
forces it to be detachable from its "environment".  This makes the code 
more composable, but it goes much further than that:  The TDD process 
actually drives the design, and, one step further still - leads to an 
"emergent" design method.  So, adding a fourth point, the summary is 
that TDD is for

1. verifying logic;
2. detecting programming mistakes;
3. promoting a clean, and even emergent design;
4. making it so you can re-factor without breaking your code.

(apologies to TDD people if I misunderstand something)

Now, Haskell is *very* good at giving you 2, 3 and 4.  I have no idea 
whether Haskell gives 2, 3 and 4 better or worse than C# or Java coded 
in a TDD style.  Certainly it gives it to you with a whole lot less typing.

Haskell also contributes to 1, in that the type system *can be used* to 
significantly tie down your logic, and make mistakes less likely.  But 
ultimately Haskell can't make you write your logic correctly.

I am saying that I think Haskell gives you about 70-90% of what TDD 
gives you, but with less fuss.  The remaining 10-30% you still need 
testing for.

The key point, is that in functional programming, TDD is not really 
needed to "drive the design", because the language itself does the same 
job, but in a slightly different way:  Good design is the path of least 
resistance in Haskell, and since re-factoring is so safe and easy, it 
almost automatically tends in that direction.

So I think the main purpose of TDD ("driving the design") doesn't apply 
in Haskell.  The only part of TDD that applies to Haskell is verifying 
logic, but this can be done after the fact, with the added risk (not 
shared by TDD) that you won't bother.  The way Haskell programmers 
usually work, which I think is the best practice for the language, is to 
drive the design just through plain Haskell coding, but to have enough 
self discipline to recognize where your logic needs to be verified, and 
write tests in those cases.  (QuickCheck makes it so easy!)

I would certainly urge functional programmers to grasp the (actually 
somewhat subtle) philosophy behind TDD.

 > Q: Note that TDD and "writing tests" are different things. With respect
 > to "writing tests", I know
 > that HUnit exists and that RWH has a chapter on quality assurance.
 >
 >
 > Given that, I'd like to know: how widely is HUnit used? If you were to
 > start a new Haskell project, would you
 > include HUnit (a) immediately (b) eventually (c) maybe (d) another
 > adjective ?

I personally use HUnit a lot, so I use test-framework, which gives both 
QuickCheck and HUnit.  I think the best way is to use QuickCheck if you 
possibly can, and if not, use HUnit (either for IO-bound code, or for 
situations where it's easier to specify the test cases yourself than to 
induce QuickCheck to generate them).

I do about 1/5th of my tests in HUnit, so I would always anticipate that 
I would want it, so my answer is (a).

Steve

Michael Easter wrote:
> 
> Folks,
> 
> A friend asked me about Test-Driven Development (TDD) within the FP 
> community. I realize
> the FP community is larger than a Haskell mailing list, but I wanted to 
> get a sense from this
> camp.
> 
> I'm a fan of Haskell but I can't say that I know the culture yet. That 
> said, I'm writing as *a fan* and
> not a critic. These are genuine, earnest questions.
> 
> Q: Is TDD advocated the Haskell community? Is it controversial? Is it 
> even on the radar?
> 
> Q: If TDD is not advocated: why? Is there something about the Zen of 
> Haskell development that
> is an impedance mismatch with TDD?
> 
> Q: Note that TDD and "writing tests" are different things. With respect 
> to "writing tests", I know
> that HUnit exists and that RWH has a chapter on quality assurance.
> 
> Given that, I'd like to know: how widely is HUnit used? If you were to 
> start a new Haskell project, would you
> include HUnit (a) immediately (b) eventually (c) maybe (d) another 
> adjective ?
> 
> 
> sincerely
> Michael Easter
> 
> -- 
> ----------------------
> Michael Easter
> http://codetojoy.blogspot.com -> Putting the thrill back in blog
> 
> http://twitter.com/patentlyfalse -> Satirical tech headlines (and 
> nothing but)
> 
> http://youtube.com/ocitv -> Fun people doing serious software engineering
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners