My latest pet project has been a little Clojure program that screen scrapes the TFL Oyster web site and calculates my (or yours) daily Oyster expenses. The project is hosted here: http://github.com/erlingwl/Oyster.
It took me a while to get comfortable with Clojure and to actually become able to write some tests. I had very much the same experience as my colleague Sam Newman writes about.
However, once I actually started doing proper TDD, I found my program evolved quite naturally. The problem might be that some unit tests are testing single functions, whilst others are testing more aggregate functions. My initial thought on this is that probably some of my unit tests are closer to what you might call acceptance tests. However, I am not sure how well this approach would scale, and as Sam mentions, one might have to stub out the sub functions in order to only test the specific function..
If you take a look at the source code, you can see I used two different ways of testing my app traditional unit testing using clojure.contrib.test-is and cuke4duke which is cucumber for various languages on the JVM including Clojure. As there is not too many examples of how to test Clojure out there, hopefully someone might find it useful to take a closer look at what I have done so far. The cuke4duke scenarios are not very impressive in their current state though, as they were amongst the first things I wrote. A reasonable approach forward would be to convert some of the acceptance test like unit tests into scenarios.
Anyway, playing with Clojure has been fun, and it has given me valuable insight regarding the future of languages on the JVM, expect a blog post on this topic soon!
An Innovator's scribblings 