Do I need to use TDD?

You have a broken phone. Sorry, but let’s assume. So you buy yourself a latest model that is strong enough to survive accidental drops (tested by dropping on concrete floor from a height of 6 ft., claims the manufacturer). You have a great time using it for personal and work life. However, a few days later, on a family beach picnic, your new phone hits a rock and succumbs to injuries. You are shocked. Scarred by this incident, you wonder if the manufacturer could not have been more thoughtful and tested the mobile phone on rocky surfaces too.

Software products are not different; they operate perfectly at first, but as you use them, you become aware of ‘bugs’ and technical glitches – some debilitating. Test Driven Development (TDD) is a practice used by developers to imagine possible failures and pre-empt them to create superior quality software products.

How TDD improves software quality?

TDD is a software development process wherein test scripts / test scenarios are created even before the code is written. This helps developers become aware of all scenarios in which their code could fail as well as all conditions it must fulfill, so that when they are done programming, they will have very few errors. TDD puts the notion of fail fast and repair quickly into practice. So, the basic idea behind TDD is to write and fix failing tests before developing new code.

The framework of Test-driven Development is ‘Red, Green, and Refactoring’. First unit tests are written to check the correctness of the code.

(Unit testing is a method of testing a unit, which is the tiniest bit of code in a system that can be logically detached. This is similar to the unit assessments given to students, in which their knowledge is examined in small increments to give them a sense of how to prepare and develop for the semesters ahead.)

Typically, in software engineering, unit tests are created after some sort of development is over. In TDD, you build unit tests first and then write code to pass those unit tests. If the code fails it is red; changes are made to make the code show a green signal. Next comes refactoring. Refactoring is a technique of restructuring codes without impacting their exterior performance. It is the process of improving the internal structure of current source code while maintaining the program’s exterior behavior.

The smartest way to make a component refactorable is to provide automated regression tests. Such tests are often constructed without a complete grasp of what the component does internally, as long as the input and output protocols are understood.

Is TDD really necessary?

Just as we humans rely on the opinions of others to improve ourselves, codes rely on test cases and automated inputs from within the program to improve their quality. But for years the most habitually asked question about TDD is: “Is it necessary?” Most developers consider it time-consuming. Many have invalidated TDD owing to its intricate procedures. They do not want to test their code unless they are familiar with the application they are developing. They feel that these tests are like entering a forest of beasts – unstructured and almost mysterious.

Practitioners of TDD argue in favor of it; here is why: to them, it is like destroying the beasts one by one as you enter the forest instead of facing them all together at the showtime. They want to test their codes before writing the program so that these tests fix the bugs in the code saving the whole effort of restructuring the program in the end.

Here is what Kent Beck, founder of extreme programming (an agile development method) and pioneer of software design patterns, has to say: “TDD helps you to pay attention to the right issues at the right time so you can make your designs cleaner, you can refine your designs as you learn”.

Many TDD adherents acknowledge that tests should be used as a tool to explore around in the application design.

What we learnt from developing software through TDD

TDD could come across a time consuming and tedious process. And its repetitiveness may get on the last nerve of developers. However, at Rawdata, our developers see TDD as a coding culture. It fosters a growth mindset by making developers comfortable with change when they are developing the software product. In fact, we have seen that, with practice, it saves time and effort, contrary to popular belief.

Another cultural shift we have seen is in the relationship between developers and testers. Developers and testers generally come from different planets; their mindsets differ extraordinarily. For example, developers test their code with the intention of not breaking anything, but when we have strict test cases in place, there is no other choice other than fixing the identified issues. Our developers began embracing the testers’ perspective since they started to work in TDD environment. This improved empathy and collaboration.

Also, when compared to traditional development methodologies, we find that TDD has substantially higher test coverage. This is because TDD emphasizes the creation of tests for each component from the start. It enhances the creator’s efficiency and contributes to the formation of a convenient and easy framework. In fact, one of our customers located in Canada was so excited about TDD and our test coverage that he returned to us for developing their next product.

TDD, in our opinion, is a great methodology for writing good, long-lasting codes, and it surely accelerates the program’s testing process. When properly implemented, it has the potential to provide developers and clients precisely what they require.

“If you’re not doing test-driven development, you’re doing debug-later development” – Anonymous.