[macosxnerd101]

I found an interesting article on the basics of FP, including a discussion on TDD. Have others had to change the way they handle TDD for FP? What about other coding practices? How is FP different for you?

Quote

Whenever we start to use a new paradigm, we confront the problem of our old rules and our old habits. We ask ourselves whether all those rules and habits are valid in the new paradigm. Consider, for example Test Driven Development. Is it valid in Functional Programming? If so, how do you do it?

http://blog.8thlight..._medium=twitter

[cfoley]

The whole "functional programming is easier to reason about" is kind of seductive but that's only a a small part of unit testing. I have a dirty secret and I bet it's one I share with most coders. I seem to have an inability to get a simple line of code to compile first time. Those that do often don't do exactly what I meant. It's not that my logic is flawed or that I've forgotten corner cases. It's just that I'm prone to silly mistakes.

It's not that big a deal but since I started unit testing my code these silly mistakes have been a lot quicker to clean up. I'm sure I would make just as many silly mistakes typing functional code.

The more important part of unit testing is if I have two functions: f(x) and g(x). If I call f(g(x)) it's prone to breaking if I change either f(x) or g(x). In imperative programming, a comprehensive test suite alerts you to problems that arise through changing code and I don't see why this should be any less valuable in functional programming.

[Tayacan]

Actually, functional programming lends itself easily to TDD, because it's so simple to write tests for most things. Really, it's a unit testers dream. Writing unit tests for an OO program, however, can be harder, because you have to keep track of both return values and state.