TDD is like snowboarding

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

“I do not use this methodology (TDD) because the main question for me remains unanswered. I know that using TDD reduces the number of bugs, but what about the time required when working on this methodology?
I would like to know how time changes to develop a corporate application using TDD - decreases, increases or remains unchanged.
I hope you can answer as TDD and BDD interest me very much. ”


The first and most important thing I would like to draw attention to is the mistaken idea of ​​TDD as a tool for reducing 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 in favor of TDD is the consistent development of the design of each component of your system by writing a test for it.
')
Regarding the following question:

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

When you first decide to climb the mountain and risk a ride on a snowboard, you climb there with a dream in your head about how to dissect a few minutes and make tricks better than SSX 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 how to at least just slide down the mountain without any glitter or charm. If you are prudent, you will spend time on training with a qualified instructor who will teach you the basics and put the technique in a day. On the basis of 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 decided to master), at the beginning you need to spend time on training. Most people who decide to plunge into TDD are aware that there are many gaps in their knowledge that can create problems in this new world. Even if you have everything 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 obstacles in moving to TDD — developing a new programming style that makes you think of 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. - an approach that checks the state of an object after passing a test ). As soon as you put your hand on state-based testing, you can combine it with interaction-based testing ( from translation - an approach that tests the interaction of objects, the behavior of methods, the sequence of their calls, etc. ).

When you start using TDD, you may find that you are working more slowly than usual - this is mainly because 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 while working on a project, since TDD has become involved in your work, you will understand 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 the project. The TDD team adapted to the tasks and changing requirements is much better than the one that did not use TDD. I have observed the effect of TDD many times on a variety of projects - from small to huge enterprise-level projects. I would not talk about the benefits of TDD if I did not feel that it really deserves attention. As for me, this approach has completely changed my view on solving problems in programming.

Like many other features of programming and approaches to solving problems acquired by developers, TDD becomes another signature feature of your programming style. When solving a problem, you must first write a falling test in order to understand the requirement you want to implement.

In general, you must decide to follow the TDD long enough for it to become an integral part of your working approach. Otherwise, you risk giving up too soon, never knowing the benefits TDD can bring to your developer’s arsenal.

For those of you who are seriously considering using TDD, but have not started yet - perhaps now is a good season to try to climb the hill!