Holy crap, this TDD thing is one heckuva mindf*%#@!

The concept, I can dig. Write your tests, get it to compile, then get it to pass. I thought it mapped nicely to my normal coding practice, which is to start writing code making up objects and methods as you go, then fill in the blanks.

Turns out my method is working against me. I'm in the midst of writing my tests and I can't even get to the end of the test before I start creating my objects. For example, I started writing the following test:

        [Test]
        public void CanCreateJob( )
        {
            Job job = JobFactory.CreateJob( );
            Assert.IsNotNull( job );
        }

The problem is, as soon as I pressed enter on the first line of code in this method, I went barrelling through the Domain project creating the Job class. Before I even finished writing the test, let alone trying to compile and run it. And I shouldn't even *have* a Domain project yet.

So everything you've heard is true. It's what people used to call a "paradigm shift" back when the phrase had some meaning. It takes discipline and people will probably poo-poo it if it scares them too much (was that really less than a year ago?).

On that note, after reading more extensively on the subject, I now tend to agree with a friend of mine, a developer-who-doesn't-blog-but-should who is fairly senior but relatively new to TDD, and who said that TDD is at the place OO was ten or fifteen years ago. That is, it's not quite widely accepted but eventually it will be the de facto standard (in one form or another).

And hopefully by that time, all the little golden nuggets about it will be codified so that I don't have to highlight them in various blog posts/books.