[danso]

The more I try to explain TDD, the more I realize that some of my favorite concepts, like the ability to mock functionality of an external process because the details of that process should be irrelevant...is just beyond the grasp of most beginners. That is, I thought/hoped that TDD would necessarily force them into good orthogonal design, because it does so for me...but it seems like they have to have a good grasp of that before they can truly grok TDD.

Has anyone else solved this chicken and the egg dilemma?

[fleitz]

Test Driven Design doesn't fundamentally solve any problems, it's a tool for master craftsmen to tease out subtle errors in their design. The problem is junior programmers can't recognize bad design so they end up writing tests for a bad design, because they don't understand how bad the design is, they don't understand how to break it.

IMHO junior programmers tend to think that over specifying a design helps them, only a master can recognize the brilliance of something like SMTP/REST/JSON over X400/SOAP/XML. TDD just helps them over specify their bad designs.

That said TDD is a wonderful tool in the hands of a master. It's like photography, a $10,000 camera won't help you solve your composition problems. Tech can help ensure Ansel Adams doesn't take a photo with the wrong focus, but a properly focused poorly composed image does not a masterpiece make.

[searls]

This was indeed my motivation for writing the post. I think the next step to take if you agree with my premise is that we need to come together with ideas for how to best teach TDD to beginners/novices. Exercises that promote these concepts, lines of reasoning to take, tools to get people started without any unnecessary cognitive overhead, etc.

I agree that teaching TDD exactly how I do it today can be a bit overwhelming from a tooling perspective currently, but conceptually I think visualizing it as a reductionist exercise with a tree graph of units is pretty simple.

[bphogan]

One thing I do with my beginning programming students (since their programs are tiny) is make them write out "test plans" on paper before they can write their program code.

They have to write the inputs and then the expected results.

It gets them thinking about the concept of using tests as part of the design practice.

Later, I give them the unit tests and they have to write the code. This is usually a rewritten version of a previous program so they see the text-based test plans in action as unit tests.

Then I might give them the empty test and an empty implementation, asking them to fill in the test first, then the implementation.

Finally I ask for a completely new feature, and they have to figure out how to write the test. And I ask them to go about it with a test plan.

After a few semesters of this, I think I'm ready to say that this is successful for getting the "beginners" there.

It doesn't address everything, but I think it's a good start.

[steveklabnik]

This is the point of the blog post, no?