TDD

Test Driven Development (TDD) is a minimalistic software development process

that is driven by an automated test case which defines the desired enhancement to
the system. The test is first executed to fail. The developer then comes up with a
minimal code that will pass the test case. Once the new code is tested, it is
refactored to adapt to standards and retested. The cycle is then repeated to add
further enhancements.
1.Refactoring: Refactoring is a technique where you make a small change to your
existing source code or source data to improve its design without changing its
semantics. Examples of refactorings include moving an operation up the
inheritance hierarchy and renaming an operation in application source code;
aligning fields and applying a consistent font on user interfaces; and renaming a
column or splitting a table in a relational database. When you first decide to work
on a task you look at the existing source and ask if it is the best design possible to
allow you to add the new functionality that you're working on. If it is, then proceed
with TFD. If not, then invest the time to fix just the portions of the code and data
so that it is the best design possible so as to improve the quality and thereby reduce
your technical debt over time.
2.Test-first development (TFD): With TFD you write a single test and then you
write just enough software to fulfill that test. The steps of test first development
(TFD) are overviewed in the UML activity diagram of Figure 11. The first step is
to quickly add a test, basically just enough code to fail. Next you run your tests,
often the complete test suite although for sake of speed you may decide to run only
a subset, to ensure that the new test does in fact fail. You then update your
functional code to make it pass the new tests. The fourth step is to run your tests
again. If they fail you need to update your functional code and retest. Once the
tests pass the next step is to start over.
1. Avoid functional complexity
Keep functionality to be achieved simple. Deliberate on it with the whole team to
ensure the test case covers the desired functionality in every way possible. As the
test case is the driver here, it should be reviewed for correctness and completeness.
2. Focus on what you need to achieve
Be sure you understand where the code needs to be called and frame the test suite
accordingly. Ensure test cases follow standard naming conventions and clearly
depict what needs to be achieved by the end of development process. This is
crucial as functionality keeps getting added with iterations. Future developers
should be able to look at the test and easily deduce the intended functionality.
3. Maintain code austerity
Ensure your code has just enough meat to satisfy your test case. This is a basic
tenet of TDD. This minimizes the chances of defects and also simplifies review
and testing processes. However, do ensure the code is understandable and allows
future enhancements.
4. Test repeatedly
Test before coding and after coding. Then test once again after code refactoring.
This is to reinforce that no code is broken in any of the steps. During refactoring,
ensure the new code is maintainable and adheres to standards. The rule of thumb
here is repeat testing whenever there is a code change or code move or code
merger.
5. Maintain code sanctity
Use version control tools to check out and check in code. This is important,
specifically when more than one developer is working on the code. Using
continuous integration tools like Jenkins can avoid code merger issues.
6. Application knowledge
In TDD, coding needs to be limited but effective in that it achieves its purpose
without breaking anything else. Also, the new code should ideally pass the test
case in the very first run. Maintaining adequate system documentation, including a
repository of test cases and engaging team members with good application
knowledge can ensure a smooth and successful project execution.
7. Know when to use TDD
Last but not the least, TDD, like any other development concept, works best in
certain scenarios. Use TDD for developments that can be quickly tested. Any
testing that is prolonged or complex defeats the purpose of TDD.
Benefits:
 Many teams report significant reductions in defect rates, at the cost of a
moderate increase in initial development effort the same teams tend to report
that these overheads are more than offset by a reduction in effort in projects'
final phases
 Although empirical research has so far failed to confirm this, 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 and coupling