Excellence in Software Engineering
TDD is not about testing but the design
15 January 2017

Author: İsmail Alper SAĞLAM, Technical Team Leader – Embedded Systems

Testing is and will be very important task for companies that aim to create reliable and high-quality software. Getting experience with proven methodologies like Test Driven Development (TDD) helps to get there. Despite its own challenges, a lot of advantages are shown up by the nature of TDD. Before talking about those benefits, let’s have a look at what TDD is.

What is Test Driven Development?

TDD is a cycle which consists of RED – GREEN – REFACTOR. (1)

RED: Think about a behavior from your software (Representative behavior with 5 lines of code) and write a test in two or three lines. While writing this test put yourself as the client of this code and forget that you are the developer. Run your tests and see that the RED (failing) test.

GREEN: Implement the logic which is not required to be the best one (even, you can write hard-coded staff). After that you can see all the tests are GREEN (passing). Now you are at the safe place.

REFACTOR: Because you are now sure the code is showing the required behavior, you can do any refactor you need in the code. Make your code readable, extendible and efficient. However, whatever you do, do not add any new behavior in this phase if you want to go a new RED state.

Benefits of TDD

  • Tightly couples code and the requirements because each test directly identifies a requirement.
  • Implementation that does not meet the requirements cannot exist and this simplfies the code.
  • When a bug is reported and assigned to a developer who is familiar with TDD concept, the first thing for him/her is to write the test for the specific scenario of the bug and then make the implementation for the fix with the minimum complexity which makes the scope more understandable. This means, in the future, they will never face with the problem called zombie bugs.
  • Gives each code part a purpose and this makes dead codes be disappeared by increasing code coverage.
  • Fits perfectly to agile methodology.
  • Developer cannot start implementation without properly understanding subject, since writing the test first requires comprehensive understanding for the functionality.
  • Provides very well documentation on the developer’s level.
  • No worries about breaking other people’s code.

Beside all the benefits listed, one crucial gain (but more indirectly) is that TDD would drive you to re-think your code design. This leads to a set of design principles, named SOLID, which fits TDD perfectly and enables to tap its potential. Let’s have a look at those principles.

What is SOLID code?

SOLID is the five basic design principles of object-oriented programming (2).

Single Responsibility Principle
In your code, each method and class should be changed only for one reason. TDD forces developer to write testable and single purposed code which definitely fits with this principle.

Open/Closed Principle
Your code should be open for extension and close for modification. This principle mostly achieved by using inheritance and encapsulation. If a developer uses TDD, making a code testable requires extensibility by mocking purposes. Also, modifiable code increases the chance to break unit tests which TDD people avoids a lot.

Liskov Substitution Principle
In your implementation, any reference or pointer to base class can be replaced with the derived class. TDD imposes this principle automatically since every test you run for a base class should pass for inherited class.

Interface Segregation Principle
When you create a class from an interface, inherited class should not be forced to implement unnecessary methods. For TDD people, this principle means prevention from more work by prevention from unnecessary methods.

Dependency Inversion Principle
Your implementation should rely on interfaces instead of concrete classes. This principle sits on the heart of the TDD since all mocking mechanisms imply this rule. Testing will be complex when the one uses concrete classes since their behavior cannot be changeable for test purposes.

As you can see the definitions of those principles, there is a strong link between SOLID code and TDD. TDD is a practical way to apply those principles which is key to well-designed code. Therefore, TDD is not just applying a bunch of tests differently, but more related to design.

1.) Beck, Kent. Test Driven Development: By Example. 2002.
2.) en.wikipedia.org. SOLID (object-oriented design).

Past Articles

Why Built-Operate-Transfer (BOT)?

Why Built-Operate-Transfer (BOT)?

“ In the last months we have received some BOT demands from some large enterprises especially from Europe and we had several negotiations with them. Below we want to share with our followers our impressions regarding the concerns, feelings and the alternative searches of any CEO of any enterprise in case of expanding their production into other countries.”

What if remote service is unavailable?

What if remote service is unavailable?

Today, many applications collaborate with remote services to provide functionality. While developing a distributed system, we sometimes encounter temporary remote service unavailability or failure due to transient faults such as slow network connections.