Promises, Promises
One of the guys at work has been working on introducing the concept of Promises into the system. This is an example of something that's pretty important in a distributed system, but in C#, you have to build your own. Java has java.util.Concurrent.Future, which I have no exeperience with. Lots of dynamic languages seem to include promises in their libraries; James Robertson has a couple of posts describing Smalltalk Promises.
For us, the idea of a "promise" is probably a bit different from the strict definition. In our case, we wanted a unit of work that was guaranteed to execute, and would execute asynchronously.
— Gordon Weakliem at permanent link
Dinner With the Zealot
Justin Rudd won't drink the kool-aid with his dinner. I think Justin's problem is that he's too good at programming. I suck; I can never get anything right the first time. The advantage is that my error path usually is pretty well tested by the time I have anything like working code in place.
I see a direct correlation: in code that has a test framework, my defect rate is pretty low. It's pretty high in code that has no accompanying tests. I don't really do TDD that much, strictly speaking. I don't usually write tests first. As I mentioned, the failure cases tend to write themselves, the first time I run the test.
Now as far as multithreaded or multiprocess code, Justin does have a point. Unit tests that rely on environment aren't unit tests. You have to design code that separates yourself from the environment - generally speaking, this means no relying on AppSettings (or java.util.Properties), environment variables, registry keys, etc. That should be separated into a configuration object that you use to initialize the target object. You also shouldn't really be testing thread safety or process interactions using a unit test methodology. You can, but you'll be frustrated. Let's look at the example James Robertson posted today on Smalltalk promises. It's probably not worth writing a test to check that the promise itself worked. The downloadBlock bit is something more testable, though, particularly if you were to extend it to handle things like redirects or anything with some kind of subtle logic in it.
In the comments on Justin's post, Brandon Corman mentions that TDD is a kind of formalization of what one would do in the REPL with a dynamic language. This is exactly how I feel - in a dynamic language, my tests end up being a cleaned up version of my transcript from the REPL.