TDD and Functional Programming

[Burk Hufnagel]

Venkat,
I was wondering how well Test-Driven Development works with Functional Programming and found a FaceBook posting by Kent Beck at Functional TDD: A Clash of Cultures. In it, he describes some issues he had trying to to TDD while learning Haskell, and I'm wondering if you've had similar problems trying to write automated tests in Java while using a functional approach, and if you have any suggestions on ways to make it work.

Thanks!
Burk

[Venkat Subramaniam]

Hi @Burk,

In my experience, having worked with a number of languages that provide either strict FP or hybrid FP, I have found it to be a pleasant experience to drive the design of code using tests for functional style of coding. I have found two specific benefits:

1. The purity of functions turns into fewer set up that may otherwise be necessary.
2. I often use lambdas as lightweight stubs/mocks instead of creating more complex stubs or mocks.

Overall, I have had a wonderful experience mixing TDD and FP. Neither was easy, of course, in the beginning when I was new to them.

[Burk Hufnagel]

Venkat,
Thanks for sharing your experience. I haven't gotten involved with FP yet but your book looks like a good way to get started with it.

Thanks again,
Burk

[Michał Płachta]

@Burk

I completely agree with Venkat here. I don't know if his book includes Testing/TDD. However, if you haven't seen it already, a few months ago we were discussing "Grokking Functional Programming" where there is a whole chapter dedicated to testing and TDD in functional programs

[Junilu Lacar]

This is from the article that I found as a gist:

Kent Beck wrote:When I use TDD with an object language like Smalltalk, Java, or PHP I typically start programming with a trivial case--a List with no elements, for example. Working through it encourages me (sounds better than "forces") to think about the metaphors I am using and style of the API. From there I move on to tests that encourage me to write the logic at the heart of the new code. When I can't think of any more tests that could fail, I'm done.

In Haskell, though, starting with the null case seems actively misleading. The romance of Haskell seems to come when composing solutions to smaller problems results in a solution to a larger problem. Handling the null case first gets me off track. Thinking about case analysis leads me to decomposition at the exact moment I should be thinking about composition.

It would be a good experiment to see if you run into the same problem he describes if you start with trivial cases. One of the comments on that gist points out that Kent says the opposite in 2011 in Quora. To me, this indicates an evolving perspective based on new experiences, which in this case is a good thing: it shows he's still learning.

[Junilu Lacar]

It should also be noted that the article concludes with a list of principles that are common to the two "cultures" of OO and FP.

In summary:

1. Double checking - thinking about the problem in different ways and arriving at the same answer
2. Solution decomposition - solving part of the problem doesn't invalidate other solved parts
3. Automatic verification  - the computer has to check whether results are correct
4. Outside in - externally visible behavior is more important than internal structure