Functional TDD: Codd is my Copilot
whattofix.com
whattofix.com
Remember the title is about TDD and functional programming, not about testing in general. Of course you'd still test, and debug, and all the other things involved with programming.
If you have more to offer, I'd love to hear it. I couldn't understand what you meant from your comment.
It is not always trivial to see pitfalls in pure code either (think of a complicated function like a parser). Whether you write your tests before or after you write code, you always have a at least one form of testing written (or infered) first: types. And yes, the shape of your code is influenced by your types and your tests (e.g. by making code easily testable with more meaningfull tests/propositions about it).
I never said it was trivial. And when I said it works or doesn't work, the implication was that transforms more naturally map to requirements, not that the requirements are always understood.
I guess I could have written a more complicated article full of all of these caveats, but I'm happy that testing and developing functional code is much different than imperative. Things like parsers and ASTs are more complex concepts, sure, but they are common concepts that leave little room for doubt.
I think data structures become much more important in FP for some of the reasons you've outlined. Hence my comment that those OOP skills and Codd comes in handy. This is also why used the SQL example.
But thanks for clarifying yourself. At least now I know that I disagree with you and you misunderstood the article, instead of just wondering wtf you were talking about. I'll make a note on the article to help clear up this confusion.
Where I (think I) disagree, is that I think methodology stays globally the same: I would even say that it desn't throw away TDD but gives tools to reinforce it. FP removes whole classes of nasty bugs and so it makes you test more essential stuff ; secondly the tools help you more because the compiler and the testing library know more, so for example in Haskell statistical tests are easy to write, pervasive, and often very meaningfull.