Are you looking for some concrete expression for Test Driven Development? Let me give you a glimpse of what I am working currently on – the TDD Tetrahedron.

The idea originates from when a colleague at Crisp, David Barnholdt, wrote about not focusing on one step at the time. So I thought for a while and came up with this idea, a tetrahedron where each side displayed “failing test”, “implementation” and “refactor”, respectively.

You turn it and look at the first side where you read “failing test”. You write a failing test and turn it again, reading “implementation”. Write the implementation and run the test to get the green bar. Once again you turn the tetrahedron and read “refactor”. You look for something to refactor, confident that if you do, you will be supported by unit tests all the way.

Or the thing just sit on your table to tell everyone how cool you are as being a TDD programmer. At least wish to be. 🙂

Anyways, here are some sneak preview pictures of the greatest thing that ever happened to the world of programming, ta da – the TDD Tetrahedron!

This coming spring we will host a course with Robert C Martin on advanced TDD. I would really appreciate the input from my experienced TDD readers on what they consider to be the largest obstacles when it comes to TDD. This is your chance to shape the event so that it is customized to meet your needs.

A few months ago we hosted a very popular course with Michael Feathers. He talked about refactoring legacy systems and of course, unit tests which are an essential part of that. But the crowd cried out for more.

I have been practicing TDD for two years. I program in Java and frequently use Mockito and Wicket. The latter has support for unit testing web interfaces and it is great although it has its quirks.

But what is everyone else doing?

It is not uncommon I run into a team coding a system in desperate need of refactoring,  at the same with huge pressured to move things out of the door. When trying to refactor we face the bad news of doing nothing but refactoring..

So we need to be a bit more clever. He are two ways;

Code quality. It has been haunting me for so long I forgot when I started to think about it. Do other people think about it? For sure. Do everyone? Certainly not.

I was doing RUP and before that some waterfall process from DoD. Before that I was programming Fortran. Now, what has been my single most important recommendation for reaching code quality?

Peer code review.

But enough. It just struck me how much I do not miss code reviews.

I’ll tell you why and I’ll tell you what is the replacement, because there should be one.

Your unit test should have no dependencies on anything external, you know that already. So you try not to read any files or connect to a database server.  But what about time? Recently we had some unit tests that failed during nightly build due to daylight saving. Suddenly the distance between two days was 23 hours.

But it doesn’t stop at unit tests. System tests, too, may depend on time.

You should have a strategy for how your system perceive time. Read on.

The Wicket framework is somewhat deceptive when it comes to testing, especially TDD.

När du förstått poängen med testdriven utveckling kommer givetvis krånglet. Så hur tar man sig vidare?

Vi börjar med poängen så att vi är överens om vad vi menar.

Testdriven utveckling (TDD) säger att man först skriver ett test som fallerar (viktigt), sedan implementerar man så att det inte längre fallerer.

I det läget tar man sig en funderare om man tycker att designen och kodstrukturen är enklast möjliga. Om inte så fixar man till den, utan att ändra vad koden gör, refactor på engelska. Eftersom de tester man har, går igenom så är det tryggt att ändra implementationen.

Vi fortsätter sedan med ett nytt varv, test – implementation – refactor.

Enkelt så långt, men vad är poängen?

I’ve survived my first Rocket Day. RD are our seminars at Crisp where we talk for half a day on a subject of choice. Mine was Test Driven Development with Wicket and Mockito.

I chosed to do a live coding performance as I liked to do a very down-to-earth, practical seminar.

The slides are currently in swedish but I will translat them to english. Later. 😉

However, most of you read swedish so I have published them here.

Ivar Jacobson, Pan-Wei Ng, och Ian Spence har just publicerat en ganska lång artikel i DDJ med namnet Enough of Processes: Let’s Do Practices, Part I. Det är, förvånande nog, ett ganska ärligt erkännande att dagens processer för mjukvaruutveckling inte fungerar. In the first installment of this two-part article, we examine the issues facing the