Ok that wasn’t a serious question and not aimed at Amit – I’ve been hearing this from so called “agile” folks for some time now and couldn’t resist, but snark aside,

TDD has always had a dual purpose – (1) as a design method – I’ve long been dubious of this and (2) as a way of building up a regression suite.

(2) is still valuable, though you don’t really need the “DD” part of TDD to get the benefits. You can just save your REPL tests, whether written first, last or in the middle, or while bug fixing (as Amit points out).

That said, I hereby take this opportunity spit on TDD as a design method. Referential Transparency helps in avoding the “DD” part of TDD, but even in OO/imperative designs, I’d rather substitute thinking for TDD. I’ve had to fix too many code bases “designed” through TDD.

Wonder of wonders, a lot of people do good design by thinking (deeply) about the issue at hand without resorting to crutches like TDD. Rich Hickey is a great example.

In any case you’ll still need a good test suite for said regression and continuous integration tests so we can still make changes over time without fear of breaking things.

I like to think that a minimal amount of good tests is ideal for both developing and verifying. So to me the important thing to me is, does it show how to use the function or does it show a case that needs to be handled. If I write some code to achieve something I will at least have run it in some context at some time; I want to capture that. If I find a bug, I would prefer to keep that information rather than discard it.

My work-flow to that end is roughly like this:
1) open a file and write some high level wishful thinking declarations
2) start writing some functions to support it
2.5) copy the function definitions to REPL as I create them
3) open another file and write some basic tests to check the function works
3.5) copy these to the REPL
4) iterate between the two buffers building the tests up to an example and the program toward an end goal. These eventually become similar activities and I know I’m done.
5) wrap the secondary file up in deftest
Now when I come back in a month, I can just run my tests and be happy! I guess the point of my comment is simply that saving your REPL buffers can provide some value with little effort.

That’s just what works for me at present, and I’m happy to be educated to better approaches.

(defn day [timestamp]
(quot timestamp 10))

(defn day-table [timestamps]
(reduce #(assoc %1 (day %2) %2)
{}
(sort > timestamps)))

(day-table [10 15 13 21 24 25 36 33])

user=> (day-table [10 15 13 21 24 25 36 33])
{1 10, 2 21, 3 33}

The point I want to make is that there is no conflict between using the REPL and unit tests, quite to the contrary. You can easily write small functions for testing your interactively developed code using the REPL, but once you have your functions working you can just as easily drop them into your code base as unit tests. That’s a huge benefit of interactive development that you just don’t have with those edit-compile-debug languages.

Also, I also love the convenience of using partial maps during unit testing (if your function-under-test only relies on fields x and y but not z of a map, you can pass just {:x 1 :y 2} to your function).