Misconceptions

TDD alone is sufficient for testing: The fact is, Test Driven Development and what it entails at the unit/developer test, as well as at the customer test level, is only part of your overall testing efforts. At best, it comprises your confirmatory testing efforts, but regardless of project size, you must also be concerned about independent testing efforts that go beyond this.

TDD is time-consuming: Test-driven development has become popular over the last few years. Many programmers have tried this technique, failed, and concluded that TDD is not worth the required effort. However, what actually requires a lot of your time is learning and mastering TDD as well as understanding how to set up and use a testing environment. I guarantee you that once you are familiar with the testing tools and the TDD technique, you will find that it doesn’t require more time than traditional coding. On the contrary, it helps keep a project as simple as possible and thus saves time.

Grand Rules

There are many sources and quotations you can find on the internet, but the simplest way to put it is,

• Write only enough of a unit test to fail.
• Write only enough production code to make the failing unit test pass.

Or, more practically

• write a “single” unit test describing an aspect of the program
• run the test, which should fail because the program lacks that feature
• write “just enough” code, the simplest possible, to make the test pass
• “refactor” the code until it conforms to the simplicity criteria
• repeat, “accumulating” unit tests over time

What is TDD?

“Test-driven development” refers to a style of programming in which three activities tightly interweave: coding, testing, and design. As you may be familiar, testing takes place in the form of writing unit tests, and design is pursued in the form of refactoring.

How was this born? Over the course of history, testing and validating have been taken in and out of developers’ hands as different development models come and go. Fundamentally, our communities realized that it is always better to have an external source to verify any work, but it is certainly more efficient if the original codes are clean and have better code coverage.

So, let’s say you have just finished a small feature. Do you consider it enough to test this feature just by interacting manually with the browser? It’s not likely that it’s enough to rely just on tests done by developers manually. Unfortunately, this means that part of the code is not good enough. And before getting into the actual testing techniques, there is a bare minimum that everyone can contribute to. Therefore, it is safe to say that TDD is a principle many developers have adopted to achieve good-quality code and test coverage.

Expected Benefits

Many teams report significant reductions in defect rates at the cost of a moderate increase in initial development effort, and these overheads are more than offset by a reduction in effort in projects’ final phases.

Although there is no tangible data to confirm this, the impact varies depending on the organization due to the reason it takes quite some commitment to master TTD. However, veteran practitioners report that TDD leads to improved design qualities in the code and, more generally, a higher degree of “internal” or technical quality, for instance, improving the metrics of cohesion.

Summary

Test Driven Development is a development technique where you must first write a test meant to fail before you write new functional code. Agile software developers have quickly adopted TDD for various development of application source code, and it has also recently been adopted for database development. TDD itself is rather a code of conduct to encourage clean coding practices than a technique, which should be seen as complementary to Agile Model Driven Development as they work well together. As previously mentioned, TDD does not replace traditional testing. Instead, it defines a proven way to ensure effective unit testing to save rework later in development.

From a testing specialist’s standpoint, TDD can also positively affect productivity because it dramatically shortens the feedback cycle between introducing a bug and fixing it – i.e., the developer notices the bug because one or more tests fail and then fixes it, so the tests will pass again. This, in turn, reduces bugs ‘leaked’ to the QA team, reducing their burden and freeing up time to work on tasks such as test automation and integration testing.

We at SHIFT ASIA thrive on working with both waterfall and agile development teams, ensuring we are a good addition to the existing organization to achieve higher productivity, integrity, and quality in output.