THE BENEFITS OF TDD

When describing TDD to developers, development managers, and project managers who have never
experienced it, I am usually met with skepticism. On paper, creating code does seem like a long and
convoluted process. The benefits cannot be ignored, however:

➤ TDD ensures quality code from the start. Developers are encouraged to write only the code needed to make the test pass and thus fulfill the requirement. If a method has less code, it ’ s only logical that the code has fewer opportunities for error.

➤ Whether by design or by coincidence, most TDD practitioners write code that follows the SOLID principals. These are a set of practices that help developers ensure they are writing quality software. While the tests generated by the practice of TDD are extremely valuable, the quality that results as a side - effect is an incredibly important benefit of TDD.

➤ TDD ensures a high degree of fidelity between the code and the business requirements. If your requirements are written as tests, and your tests all pass, you can say with a high degree of confidence that your code meets the needs of the business.

➤ TDD encourages the creation of simpler, more focused libraries and APIs. TDD turns development a bit on its head, because the developer writing the interface to the library
or API is also its fi rst consumer. This gives you a new perspective on how the interface
should be written, and you know instantly if the interface makes sense.

➤ TDD encourages communication with the business. To create these tests, you are encouraged
to interact with the business users. This way, you can make sure that the input and output combinations make sense, and you can help the users understand what they are building.

➤ TDD helps keep unused code out of the system. Most developers have written applications in which they designed interfaces and wrote methods based on what might happen. This leads to systems with large parts of code or functionality that are never used. This code is expensive. You expend effort writing it, and even though that code does nothing, it still has to be maintained. It also makes things cluttered, distracting you from the important working code. TDD helps keep this parasite code out of your system.

➤ TDD provides built - in regression testing. As changes are made to the system and your code, you always have the suite of tests you created to ensure that tomorrow ’ s changes do not damage today ’ s functionality.

➤ TDD puts a stop to recurring bugs. You’ve probably been in situations where you are developing a system and the same bug seems to come back from QA repeatedly. You think you ’ vefinally tracked it down and put a stop to it, only to see it return two weeks later. With TDD, as soon as a defect is reported, a new test is written to expose it. When this test passes, and continues to pass, you know the defect is gone for good.

➤ When developing applications with testability in mind, the result is an architecture that
is open, extensible and flexible. Dependency Injection is a key component of both TDD and a loosely coupled architecture. This results in a system that by virtue of its architecture is robust, easy to change, and resistant to defects.

read more...

THE CONCEPTS BEHIND TDD

The history of TDD starts in 1999 with a group of developers who championed a set of concepts
known as Extreme Programing (XP). XP is an agile based methodology that is based on recognizing
what practices in software development are beneficial and dedicating the bulk of the developers
time and effort to those practices under the philosophy “ if some is good, more is better. ” A key
component of XP is test - first programming. TDD grew out of XP as some developers found they
were not ready to embrace some of the more, at the time, radical concepts, yet found the promise
of improved quality that was delivered by the practice of TDD compelling.

As mentioned, agile methodologies do not incorporate a big upfront design. Business requirements
are distilled into features for the system. The detailed design for each feature is done when the
feature is scheduled. Features, and their resulting libraries and code, are kept short and simple.


TDD as a Design Methodology
When used as an application design methodology, TDD works best when the business user is
engaged in the process to help the developer define the logic that is being created, sometimes going
so far as to define a set of input and its expected output. This is necessary to ensure that the
developers understand the business requirements behind the feature they are developing. TDD
ensures that the final product is in line with the needs of the business. It also helps ensure that
the scope of the feature is adhered to and helps the developer understand what done really means
with respect to the current feature in development.


TDD as a Development Practice
As a development practice, TDD is deceptively simple. Unlike development you’ve done in the past,
where you may sit down and start by creating a window, a web page, or even a class, in TDD you
start by writing a test. This is known as test first development , and initially it might seem a bit
awkward. However, by writing your test first, what you really are doing is creating the requirement
you are designing for in code. As you work with the business user to define what these tests should
be, you create an executable version of the requirement that is composed of your test. Until these
tests pass, your code does not satisfy the business requirement.

When you write your first test, the first indication that it fails is the fact that the application does
not compile. This is because your test is attempting to instantiate a class that has not been defined,
or it wants to use a method on an object that does not exist. The first step is simply to create the
class you are testing and define whatever method on that class you are attempting to test. At this
point your test will still fail, because the class and method you just created don ’ t do anything.
The next step is to write just enough code to make your test pass. This should be the simplest code
you can create that causes the test to pass. The goal is not to write code based on what might be
coming in the requirement. Until that requirement changes, or a test is added to expose that lack
of functionality, it doesn’t get written. This prevents you from writing overly complicated code where a simple algorithm would suffice. Remember, one of the goals of TDD is to create code that is
easy to understand and maintain.

As soon as your fi rst test is passing, add more tests. You should try to have enough tests to ensure
that all the requirements of the feature being tested are being met. As part of this process, you want
to ensure that you are testing your methods for multiple input combinations. This includes values
that fall outside the approved range. These are called negative tests . If your requirement says that
your interest calculation method should handle only percentage rates up to 20%, see what happens
if you try to call it with 21%. Usually this should cause an exception of some sort to be thrown. If
your method takes string arguments, what happens if you pass in an empty string? What happens
if you pass in nulls? Although it ’ s important to keep your tests inside the realm of reality,
triangulating tests to ensure the durability of your code is important too. When the entire
requirement has been expressed in tests, and all the tests pass, you ’ re done.

read more...

The Principles and Practices of Test-Driven Development

These methodologies are all different in how they are implemented, but they share some
characteristics:

➤ They all make communication across the team a high priority. Developers, business users,
and testers are all encouraged to communicate frequently.

➤ They focus on transparency in the project. The development team does not live in a black
box that obscures their actions from the rest of the team. They use very public artifacts
(a Kanban board, a big visible chart, and so on) to keep the team informed.

➤ The members of the team are all accountable to each other. The team does not succeed or
fail because of one person; they either succeed or fail as a team.

➤ Individual developers do not own sections of the code base. The whole team owns the entire
code base, and everyone is responsible for its quality.

➤ Work is done in short, iterative development cycles, ideally with a release at the end of
each cycle.

➤ The ability to handle change is a cornerstone of the methodology.

➤ Broad strokes of a system are defi ned up front, but detailed design is deferred until the
feature is actually scheduled to be developed.

Agile methodologies are not a silver bullet. They are also not about chaos or “ cowboy coding. ” In
fact, agile methodologies require a larger degree of discipline to administer correctly. Furthermore,
no one true agile methodology exists. Ultimately, each team needs to do what works best for them.
This may mean starting with a branded agile methodology and changing it, or combining aspects of several. You should constantly evaluate your methodology and do more of what works and
less of what doesn ’ t.

read more...