

Functional TDD: Codd is my Copilot - DanielBMarkham
http://www.whattofix.com/blog/archives/2010/09/functional-tdd.php

======
plesn
mmh, no. Functional programing is declarative, but I does not mean I don't
declare utterly wrong and nonsensical things to my compiler. That's why I have
not only a type system, but also testing tools even for pure code: see
Quickcheck in Haskell. But, yeah, I often have less state to manage and
patterns that avoid a lot of buggy boilerplate.

~~~
DanielBMarkham
I'd really love it if you would explain yourself a little better.

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.

~~~
plesn
FP code can still be in mismatch with your thoughts about it, so functionnal
programming does not magically "just work", nor does "it works or it doesn't
work" (except in the dumb sense of this sentence which applies to all code).
You still write tests even for pure functions to check that certain
assumptions hold just like you would in Python, except you also have types to
prove certain assumptions.

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).

~~~
DanielBMarkham
Meh. I'm not buying 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.

~~~
plesn
Ok, so I (think I) agree with you that the following poperties make it
compelling to test/develop/refactor code: purity / statelessness, algebraic
properties of programs (transforms…), high level (brevity).

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.

~~~
DanielBMarkham
I really like your statistical testing example. I haven't seen a lot in the
agile community about statistical testing, but in data transformation-like
code, as you say, it can be very meaningful.

