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 did exactly this, in a previous job where we were required to unit-test a lot more than I liked. I always mess around with stuff in the REPL a lot anyway, and it was dead simple to write an Emacs command to turn my REPL sessions into unit tests.
It's not as useful as you'd think -- the only way to structure the tests is by the class or function the comment is on, and you have to go out of your way to avoid default __repr__ returns of the form "<object foo at 0xADDRESS>", as the expected response handling is ANAL.
This 'play with some inner bit until you understand it' technique is interesting in a couple of ways. It means you're bringing the code to life piece by piece; and it means you're reading it inside-out. Both of those things were revelations to me.
As an aside, this gets harder to do to the degree that the code is written in an OO-style (even in Common Lisp) because you typically have to create other objects before you can bring code to life, which is usually not obvious how to do and bogs the process down.
Does programming language affect level of anxiety? Definitely. Does programmer skill affect level of anxiety? Absolutely.
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.
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.
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.
Sorry, but I think this is bullshit. If it were true, you could replace unit testing by medication.
And I don't have to worry about side effects from writing tests.
You're taking me too literally when I say I want to manage anxiety. If medication is a solution, so is not hacking at all, or just remaining inexperienced and non-introspective about my coding. Anxiety usually has good reason, and it requires improving the _codebase_. But my metric for how the codebase is doing is my own perception as I live and breathe it.
I have a love-hate relationship with anxiety. I need to listen to my perceptions, because that's key to where the code comes from. But those perceptions also have the ability to demotivate me away from the code. It seems like an obvious connection to me ever since my experience with burnout. Learning about the non-linearities in my motivational structure makes me a better programmer.
Has Kent Beck influenced me? Definitely. Listening to myself works for me. I don't see how thinking more about how I operate and how I learn my skills can do more harm than good. Paraphrasing Sun Tzu, "Know yourself". http://en.wikiquote.org/wiki/Sun_Tzu
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 what you want to happen, rather than how.
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.
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.
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.
