Fortsätt till huvudinnehåll

A month of TDD

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:
  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  3. 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.

Fortunately I have had some help by Michael Feather's book Working Effectively Legacy Code.
To make it even harder the code that I have been changing is involved in inter process communication and uses multiple threads, global static variables, and thread barriers in the form of Manual Reset Events. Phew! It has been a challenge.

Now onwards toward month number two!

Kommentarer

  1. Spännande!
    Verkar ha varit tufft! Hur tycker du att det har påverkat koden du ändrat i? Har den blivit bättre av att du infört tester? Har du fått ändra mycket? Lagt onödigt mycket tid på en liten ändring? Känns det värt det? Många frågor :)
    Lycka till med månad två!
    Kan vi inte ta en lunch snart?

    SvaraRadera
    Svar
    1. Visst är det!
      Jag har fått ta till lite "fula knep" för att få en del av den befintliga koden testbar utan att riskera att förstöra något. Så vissa delar ser lite underliga ut efteråt. Här har jag dock valt att lita på Michael Feathers och det han skriver i sin bok "Working Effectively with Legacy Code", att det är värt att det ser lite knasigt ut ett tag för det kommer löna sig mångdubbelt på sikt. Men jag har inte behövt ändra så jättemycket och förhoppningsvis blir det lättare att ändra i just de delarna av koden nästa gång det behövs en ändring där.
      Tyvärr är det väldigt mycket kod som saknar unittester så varje ändring just nu kräver ganska mycket jobb, det bör dock bli bättre och bättre med tiden :).

      Angående lunch så absolut! Var är du stationerad nu för tiden?

      Radera
    2. Blir kul att följa din quest :)
      Jag sitter på Lindholmen, men vi kan ju mötas upp någonstans. Jag ringer imorgon!

      Radera

Skicka en kommentar

Populära inlägg i den här bloggen

Codility tasks - Part I

I was recently faced with two codility tasks when applying for a job as an Embedded Software Engineer. For those of you who arn't familiar with Codility you can check out their website here:  www.codility.com Task one - Dominator The first task was called Dominator. The goal was to, given a std::vector of integers, find an integer that occurs in more than half of the positions in the vector. If no dominator was found -1 should be returned. My approach was to loop through the vector from the first to the last element, using a std::map to count the number of occurences of each integer. If the count ever reached above half the size of the vector I stopped and returned that integer and if I reached the end without finding a dominator I returned -1. So was that a good approach? Well, the reviewer at the company rated the solution as 'pretty ok'. His preferred solution was store the first integer in the array and set a counter to 1. Then loop through the remaining i

C# Enum as bit field

Bit field enum Whenever you wish to express combinations of properties of an object, bit fields are a good way to accomplish this. As a simple example, consider a file in the file system. It can be Readable , Writable , Hidden or a combination these. The different attributes can be defined as an enum : [Flags] public enum FileAttribute {   None      = 0b0000;   Readable  = 0b0001;   Writeable = 0b0010;   Hidden    = 0b0100; } To indicate that this enum is expected to be used as a bit field I have defined it with the FlagsAttribute . It is important to understand that the FlagsAttribute does nothing more than making some changes to how the ToString method of the enum works, making it possible to print out all flags. It does not introduce any validation or special treatment of the enum in any other way. I have defined the values of the different fields of the enum using binary representation, this should make it even more clear that this is a bit field and which bi