Test-driven Development and How to Use It Effectively

What is TDD?

TDD is an acronym for test-driven development. It is widely known in the IT industry because of Kent Beck's book on software engineering called Extreme Programming. This bestseller presents a new method of software development - extreme programming.

The meaning of 'extreme programming' lies in the main idea of this method - to bring the usual programming practices to the limit of perfection. That's why TDD is one of the most often recommended methods.

Extreme Programming (XP) is an agile software development method that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile methods regarding appropriate engineering practices for software development.

Basics

The picture below shows the classic TDD model:

The TDD model reflects the three steps of this method.

Writing a test case of a failed test for a function.
Creating the correct code for the function to pass the test.
Refactoring the code.

The assumption is that development through testing is to start by creating tests and only then moves on to writing code. This is a misunderstanding. Test first, then code is more about Test-First Development, not Test-Driven Development.

The difference between the second concept and the first is in the 'driver' or, more specifically, in one step: refactoring!

In conventional development, many people think the feature is finished once it passes a test. In reality, this is ignoring fuzzy code, so basically, problems that may affect the next step.

Refactoring allows you to optimize code by eliminating problems in its structure. This test-driven work serves as a 'driver' for the programmer to write better code.

It follows from the above that testing and refactoring complement each other. Without testing, refactoring will be done by the programmer 'at his/her own risk'. And without refactoring, the code's mess will gradually increase, and the tests will become more and more difficult.

How to perform TDD effectively

To get TDD right, it's worth learning from professionals.

Since TDD has become very popular, Kent Beck has devoted a separate book to this method called 'Development through Testing.' Its basic idea can be expressed as follows: decomposition into tasks.

Kent Beck breaks each large task into several smaller tasks and writes them down in order of priority. Then he starts creating tests, writing code and refactoring. After completing each small cycle, the completed task is crossed off the list and Beck moves on to the next.

The reason is that Kent Beck breaks tasks down into small enough tasks to ensure that the code is presented in the best possible way after each task is completed.

A separate task might include updating the version of a dependency or changing a variable name - something that a typical developer wouldn't bother with much. The main advantages of Kent Beck's tactic are that it allows you to create adequate tests with a guaranteed ability to stop at any time.

So what are the benefits?

Task decomposition forces you to focus on a limited amount of content to think more carefully about the details. For most people, the magnitude of the task they can handle is limited. So they can't tackle a large-scale problem without breaking it down into its component parts.

And any decomposed and modified code won't be too big, which will keep the development process under proper control.

TDD is a tool for professionals

So, the TDD method introduced new ideas into software development.

Break large tasks into smaller ones and repeat the three steps each time:

WRITING TESTS

PASSING TESTS

REFACTORING

This practice will not only improve the quality of the code but also will increase your productivity.