TDD is like snowboarding

I just received the following letter, which I want to share and answer in public.

“I do not use this methodology (TDD) due to the fact that the main question for me remains unanswered. I know that using TDD reduces the number of bugs, but what about the time it takes to work on this methodology?
I would like to know how the time for developing an enterprise application using TDD changes - it decreases, increases or remains unchanged.
I hope you can answer, as TDD and BDD are very interesting to me. ”


The first and most important thing that I would like to draw attention to is the erroneous idea of ​​TDD as a tool to reduce the number of bugs. Although this is one of the “side effects” of TDD, it is not the main motive for using it. The main argument for TDD is the consistent development of the design of each component of your system by writing a test for it.

As for the following question:

“I would like to know how the time for developing an enterprise application using TDD changes - it decreases, increases or remains unchanged.”

When you first decide to climb a mountain and risk a snowboard ride, you climb there with a dream in mind how you will cut through a few minutes and perform tricks steeper than inSSX Tricky . But after a couple of falls you feel a weighty kick of reality and realize that it looks like it will take a little longer before you learn to at least just move out of the mountain without any sparkle and charm. If you are prudent, then spend time training with a qualified instructor who will teach you the basics and equipment in one day. Based on lessons with an instructor, you will be able to grow as a snowboarder for the next couple of months, and most likely you will not pick up bad habits that you could acquire, try to learn on your own.

As in snowboarding (and in any other new business that you decide to master), in the beginning you need to spend time learning. Most people who choose to plunge into TDD recognize that there are many gaps in their knowledge that can create problems in this new world. Even if everything is in order with knowledge, you should be aware that in any case, at first you will train your brain to solve software problems in an unusual way. In fact, this is one of the biggest hurdles when switching to TDD - the development of a new programming style that makes you think about small steps and develop an API as if it were already written. A good way to start practicing TDD is to use state-based testing (from transl. - approach in which the state of the object is checked after passing the test ). Once you get your hand on state-based testing, you can combine it with interaction-based testing ( from transl. - an approach in which the interaction of objects, the behavior of methods, the sequence of their calls, etc. are tested ).

Starting to use TDD, you may find that you are working slower than usual - this is mainly due to the fact that you will work outside the “comfort zone”, feeling unnatural. Once you feel that writing tests has become a natural part of the workflow, that you no longer need to think about using TDD when working on a project, since TDD has been integrated into your work, you will catch your “AHA!” Moment with TDD.

I witnessed the work of two teams (one of which was agile) with developers of about the same level, who were asked to implement one functionality in a project. A team practicing TDD has adapted to the tasks and changing requirements much better than one that did not use TDD. Many times I observed the effect of TDD on a variety of projects - from small to huge projects at the enterprise level. I would not talk about the benefits of TDD if I didn’t feel that it really deserves attention. For me, this approach has completely changed my view of solving programming problems.

Like many other programming features and problem-solving approaches acquired by developers, TDD is another hallmark of your programming style. When solving a problem, the first thing you should do is write a falling test to understand the requirement that you want to implement.

In general, you should decide to follow the TDD path long enough so that it becomes an integral part of your working approach. Otherwise, you risk surrendering too soon without ever learning about the benefits that TDD can bring to your developer's arsenal.

For those of you who are seriously considering using TDD but haven't started yet, maybe it's a good season to try climbing the hill!