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.
0 comments: on "THE CONCEPTS BEHIND TDD"
Post a Comment