TDD and the SOLID principles (Part 1 – introduction)

August 26, 2011

Table of contents:

Part1 – Indrocution (this post)

Part 2 – SRP

Part 3 – OCP

Part 4 – LSP

Part 5 – ISP

Part 6 – DIP

Part 7 – Conclusion


Mastering TDD is a process that takes time. There are many pitfalls that “newbie’s” fall into. IMHO the following 2 reasons are the main ones:

  1. Thinking about the implementation before writing a test. That is, writing tests that are coupled with the implementation instead of with the problem at hand
  2. Taking large steps in the TDD cycle of red-green-refactor. This tends to make long and complex tests (especially with complex setup code), that makes it hard to refactor

But once you’re mastering the technique, one of the great advantages of TDD is that it leads you to write very clean and maintainable code, as well as to constantly improve your design. This happens because when you design for testability in the small scale, you end up with a very loosely-coupled and reusable design.

One of the main obstacles to good and maintainable design of software is dependencies. Software is built using reusable components and in turn, this reusability creates dependencies. Reusability is a good thing and therefore dependencies are unavoidable. But the question is how we manage these dependencies in a way that is easy to control and maintain. For example, if you took a dependency on a 3rd party library, how do you ensure that you’ll be able to easily replace it with another one? Or if the dependency is yours and you have a bug, how do you ensure that you should fix only in one place?

The SOLID principles of Object-Oriented programming, formulated by Uncle Bob Martin, are 5 principles for building good, clean OO code, which focus on dependency management.

Even though you could theoretically use the SOLID principles to build software without TDD, it’s much more natural to do it using TDD, because TDD drives you to this direction (as long as you don’t fall into the pitfalls I mentioned earlier).

The 5 SOLID principles are:


The Single Responsibility Principle

A class should have one, and only one, reason to change.


The Open Closed Principle

You should be able to extend a classes behavior, without modifying it.


The Liskov Substitution Principle

Derived classes must be substitutable for their base classes.


The Dependency Inversion Principle

Depend on abstractions, not on concretions.


The Interface Segregation Principle

Make fine grained interfaces that are client specific.

In the next chapters I’ll go into more details on each of these principles and explain how they’re related to testability and TDD.

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



  1. ParadisApril 23, 2013 ב 8:05

    I do not know whether it’s just me or if perhaps everybody else experiencing problems with your blog. It appears as though some of the written text in your posts are running off the screen. Can someone else please provide feedback and let me know if this is happening to them as well? This may be a problem with my web browser because I’ve had this happen previously.
    Many thanks

  2. DohertyJune 30, 2013 ב 18:16

    بجد انا سعدت بموقعك واتمني
    لكم احسن حال لهذا المنتدي الجميل ووضع
    الكثير من نكت مضحكة ونكت جديدة