TheCodedWorld

A very well known book on Test-Driven Development (TDD) is Kent Beck's Test-Driven Development by Example. I have just read through the first part, The Money Example, and now I am following it by writing the code i C# (most parts translate directly from Java to C#). One of the big insights I got from following Kent's thoughts is that a lot of effort should be put into the refactoring step. Kent quickly writes a small test followed by a simple implementation to make it pass, in many cases just returning a constant value. Then the big part of the work starts, making the application code generic and clean. Refactoring the code involves removal of duplication. Here an important insight is that there might be duplication not only of code, but also of data. For example, assume that the test expects the value 10 to be returned by the application code. Hard coding the application code to return 10 is data duplication and must be removed in the refactoring step. I believe that the

I found an easy TDD kata that you can use if you want to try out some TDD. It is written by Robert C. Martin (Uncle Bob) and can be found here . The code is in Java, but it is easily translated to any other C-like OO language. I wrote it in C#. You can find my code on https://github.com/Backhage/BowlingGameKata Even though it is easy I learned some new things by doing it. If you use Visual Studio and write the code in C#, you will notice how much you can use the "Exract method" feature when doing this kata. Breaking out variables and naming them properly will make "Extract method" really handy. Give it a try!

It's soon been a month where I have gone hardcore TDD. Everything I code at home and everything I code at work has been done using the three rules of TDD: You are not allowed to write any production code unless it is to make a failing unit test pass. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. Now, at home this is quite easy to follow, since home projects are almost always green field projects. However, at work it is brown field, and worse, the code at work is legacy code (in the way Michael Feathers defines legacy code. That is, code without tests). So, I have spent a lot of time putting existing code under test. Which is not always easy when it isn't designed to be easily testable to start with. At least, the parts where I am thinking about making changes has to be put under test. Fort

Part IV is the final part of the book. It is titled "Requirements and Tools" and covers how to handle changes to the understanding of the requirements (you update the tests, add more tests if required, and change the application code accordingly), and lists a number of framework that can be used to make TDD easier. There is not much more to say about Part IV so I'll summarize the whole book instead: I was not impressed. Will pick up a copy of Kent Beck's Test-Driven Development: By Example and hope that one is a better read.

The third part of the book is called "TDD Scenarios" and handles how to test some things that usually is considered hard to test. This includes ASP.NET, services created with Windows Communication Framework (WCF), and graphical user interfaces created using the Model View ViewModel (MVVM) pattern. As in previous parts this heavily relies on third party frameworks. However, the essence is good. This is the best part of the book so far, just because it shows that it is possible to develop even these things using TDD. I would recommend looking into this part of the book if you ever are to develop something using WCF or MVVM. However, I am disappointed with the quality of the book in regards to the code samples. There are several copy/paste mistakes which are so obvious that a simple read through before sending the book to print should have been sufficient to find and correct most of them. A short review of part IV is coming up soon.