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@haskell.org http://www.haskell.org/mailman/listinfo/beginners