Clojure, the REPL and test-driven development

Tests are a technique to manage programmer anxiety about code. When I feel anxious about some aspect of my code I write a test case.<p>Does programming language affect level of anxiety? Definitely. Does programmer skill affect level of anxiety? Absolutely.<p>Writing tests becomes more important when you're part of a team. Your choices affect not just your anxiety but that of your teammates. That's why it's reasonable to be more dogmatic about TDD in a team.<p>A lot of 'getting better at TDD' is just getting better at listening to yourself. When I started programming the little anxieties would pile up until I'd painted myself into a corner. With experience I pay more attention to the little anxieties.<p>After some time doing TDD I feel less anxious just knowing that I can write a test if I want. The benefit of the tests as an artifact is secondary to me; what they primarily do is keep me from getting stressed and giving up to go play poker.

I went through the same realization and even wrote about it a few times (e.g. <a href="http://news.ycombinator.com/item?id=216108" rel="nofollow">http://news.ycombinator.com/item?id=216108</a> and <a href="http://news.ycombinator.com/item?id=238770" rel="nofollow">http://news.ycombinator.com/item?id=238770</a>).<p>Basically, the value of unit-testing everything drops considerably when you move from OO to writing mostly side-effect free code and testing expressions in a REPL. That doesn't mean that unit tests become worthless; it means there are more cases where they aren't worth doing because their cost exceeds their benefit. One area where the benefit does still exceed the cost, in my opinion, is when you're working with complex algorithms. But that's a far cry from test-everything.<p>The weakness of the test-everything school is that they don't take into account the cost of writing and maintaining tests. They act as if the benefit is non-trivial and the cost is trivial, which is why they think something's wrong with people who don't agree with them. But the cost isn't trivial.

The other half of this article, that Clojure code requires less testing, is also interesting. I've noticed the same thing myself. Once the author had specified the problem, I thought of the solution in my head "he's going to map over the epochs, rounding them to dates, and then call merge-with". Scroll down, yep, almost exactly what I had in mind.<p>I don't normally do that in other languages. I attribute a large part of that to the map/filter/reduce paradigm. Functional languages tend to have a much more expressive vocabulary than C/C++/Java. Rather than writing a for loop to filter an array, you just write (filter ...). The language is almost declarative, in that you specify <i>what</i> you want to happen, rather than <i>how</i>.<p>Tests are an important part of developing these days. They should count in pg's assertion that program shortness == power. Needing to write fewer tests to be sure of a program's correctness is an important attribute.

If your writing little functions in a REPL you get to see the results of that code immediately, in a sense, that is test-driven -- the verification aspect is present. What isn't present is the test-first aspect that ensures your code is easily testable, which is valuable. And you don't have the test code to keep in a suite to run whenever to check for harmful synergies.<p>You could probably write a REPL with the appropriate commands that would build rudimentary test code from lines you executed that did what you wanted them to.

I often use tests as quasi documentation when learning someone else's code. How does this function work? Let's check out the test.