Since I work in a shop that uses Agile methodologies, it's a bit harder for me to sneak Clojure past the boss as you suggest since my pair will start to ask questions as soon as I start typing and as soon as he tries to drive. Even if my pair became an accomplice, we would still have issues if it wasn't easily testable.
I've seen you compare Clojure to Python which is interesting for me since my shop actually used Python on a project and I got to see first hand the differences between Java and Python. All the things you say about Clojure match what I like about Python. Since I haven't had any performance issues yet, I guess I'm not 100% sold on learning Clojure.
One thing that stood out the most was how much of a difference it makes on your approach to testing when using a dynamically typed language rather than a strongly typed language. Also, the Python libraries and documentation for testing weren't as rich as Java's which really made it painful for some. So will someone switching from Java to Clojure experience the same kind of pain that we did when it comes to testing?
Basically if Clojure has everything I love about Python, but is faster and easier to test, then I'd be sold on it for sure.
When all you have is a hammer, everything looks like a thumb.
Clojure has a built-in unit testing library called clojure.test which is pretty solid. I used that for about a year and was very happy with it.
These days I use Expectations from Jay Fields. It has a couple of plugins for Leiningen: one to run your tests (lein expectations) on demand, and one to watch your project (lein autoexpect) and automatically run your tests any time your source code or test code changes - that's the main way I use it now so I have continuous feedback on my code and tests. Expectations also has an Emacs mode so you can easily run tests inside Emacs - I use this too but it's not my main workflow.
There's also Midje which provides sophisticated stubbing and mocking.
I personally still use clojure.test almost exclusively, although I've now started using test.generative in conjunction with it, which provides for the generation of data for input to tests that match whatever criteria you set. (This can be thought of as the Clojure equivalent to QuickCheck and ScalaCheck, for Haskell and Scala respectively.)
As Sean said, there is Midje and Lazytest and Expectations, all of which take different tacks at testing in general, and a couple of different shots at test watching and such. I'm afraid I can't recommend one or the other of these, as I've not used them; however, their pedigree (i.e. coming from former [current?] Ruby programmers) means that they're likely to support the kinds of TDD workflows you'd expect.
I think Clojure's REPL is the best playground for testing for my money. Having programmed in Python for years prior (and Scala after that), I was very comfortable with interactive shells and interpreters, but a proper REPL gives you a great deal of power to test and experiment with code, IMO far more than any particular testing methodology or framework. The REPL is so important, we devote a whole chapter to "REPL-Oriented Programming" in the book, and the first chapter (available free online) introduces the Clojure language by way of understanding how the REPL works from top to bottom (since, once you understand the REPL, you largely understand how the language itself works).