TDD or not TDD

Thu Sep 11 2014

I love Test Driven Development (TDD). Every time I have the opportunity to put it on practice I try to do it. Because a solely participant is as important as a little raindrop in the sea, I always try to teach TDD to my work fellows. There have to be a moment when the critic mass starts and then the technique becomes a standard. I hope so!

Well... I'm not an expert in TDD and maybe that's one of the reasons why this practice never has gained a good momentum on my company. But I'm a convinced that "la letra con sangre entra" (the english translation is something like 'no pain, no gain') and we must use it and use it and use it until we start to think in terms of test before play and pray. With the experience we can know what are the best tests for certain logic validations. TDD is more an art than a science.

Unfortunately, TDD has a lot of reluctance in my work. When I talk about the need to start teaching those kind of practices I get an answer like "yes, I like it also, but you need to see the quality of our developers. We are not the NASA". Maybe we first need to change our team with NASA developers, perhaps they are right. Or maybe we can start with some theory and practice classes, explaining the benefits and checking what's the reception. One of the big advantages of this career is that our people (the developers) has a supreme interest for acquire new knowledge. Money is always a big motivation, but the training is a main issue in this field, thanks to god.

A few days ago I received an important assignment: evaluate the cost of migrating a Silverlight application to HTML. For this I need to check what's the best and less-expensive option. The reasons why we are moving out from Silverlight are:

  • Microsoft is no longer working on this plugin.
  • The system is extremely slow under certain circumstances.
  • We have like twelve layers, between datacontracts, proxy client, WCF services, ServiceLocators, etc.
  • The development process is very slow.
  • Today HTML is capable to make most of the functionality we use in Silverlight.
  • We want the application to run in multi browser and multi devices.

This work was assigned to me and another fellow. The other guy has like seven years here and is responsible for the servers, he checks our branches in code, check our stored procedures, is our software architect, etc. He has the last word in what trends we have to take, what we can and cannot use, etc. The reason to put our two visions is to contrast them and see what's the common factor.

He is a very practical person. He puts the primary objective on first priority, over any other thing. Of course, we have no time and the company does not want to spend a lot of money for the migration. If the project takes a lot of time then they will decide to continue with Silverlight.

One of my first thoughts was to check our system, checking where I can start. My first clue was that the system has a lot of business logic in the ViewModels (the client side). So I started to read a book about refactoring, checking how I can move the logic to the WCF services o the business layer to make a very thin client. Once done, migrate the app to HTML with knockout, an extremely useful library for data-binding that serves for the Model-View-View Model (MVVM) pattern.

If you have the chance to buy the book from Michael Feathers, please do it. One of the first rules he writes in his book is to make tests to cover existing codes and then start to change if needed. It's a very reasonable logic to make test harness before starting to change code... but I have no time to make those tests. My fellow is running with his implementation because we need to have a solution early. And there is always a "it's ok, but when we have time". Of course, you can say that the invested time in testing is a saving for the future, but you cannot measure it today.

Another problem with my idea is that the Web application calls the business layer, which calls directly to the data access layer that calls stored procedures (the stored procedures has most of the business logic):

WEB -> BLL -> DAL -> Stored procedures with logic

We have a lot of coupling here... because the logic is in the database, my TDD does not make much sense. One of the principles of TDD is to isolate the piece of code that you want to test. The test has to be fast and automated. We cannot depend on have the last backup of the database, the connection to the server and so on.

So, finally I discarded the tests and decided to start with the HTML and the ViewModels with knockout. Hope once we migrated the App we can start to make test harness to refactor our code. But there is an important message here: I think we need to measure when to apply certain techniques. TDD is not the ultimate solution for your development process. I really think that this accelerate the development process, but unfortunately is very difficult to put it on practice when you are alone trying to define it as a good practice. Certainly you need an sponsor with decision power in the company.

Hope in a few weeks I can update this entry to show an advance. And if you have a comment about what's your experience with similar situations, I would be very grateful.


comments powered by Disqus