I spent the past couple of months as a mentor in the Tech Leaders program. It was a very interesting experience: I had to answer a lot of fundamental questions that I no longer even think about during my daily routine. Actually having to take a stance on some of them taught me a lot. One day I found this question in my email inbox:
“If test-driven development is so good, should I use it everywhere?”
I’m a big fan and proponent of this technique and I use it regularly. However, the short answer to the aforementioned question is no: You don’t have to use it everywhere.
Test-driven development, or TDD, is a technique where you must first write a test that fails before you write new functional code. The idea behind it is that it allows requirements to be turned into very specific test cases. It also ensures that the tests are actually meaningful. An elementary knowledge of TDD principles is required for understanding this article. This tutorial may serve as an introduction to the topic.
So when exactly is it good to use TDD?
Oftentimes, this decision is not immediately clear. In this article, I am going to provide a set of guidelines to help you decide whether or not to leverage this technique in your software development process. These guidelines will be based on these four questions:
- How complex is your problem?
- How well do you know your tools?
- Is your interface well defined?
- How important is your code?
Question 1. How complex is your problem?
Before we address this issue, let me start with another one — the ultimate question of software engineering:
What exactly is programming all about?
The answer is obviously “42”, but I’ll explain it in detail anyway. You see, programming is all about taking hard problems and turning them into simple solutions.
All article is here: click