Test-Driven Development (aka TDD) is nowadays the most
common way to develop software among architects and developers. Raise of Agile
development methodologies and the growing number of small software teams is the
main reason to choose TDD as the main option for developing software (of course
there are some other reasons as well).
I suppose that you (as readers of this article) have a
background in TDD and unit testing from the past because there is no doubt that
I cannot teach you such stuff here, but a short related introduction to the
topic of this article is mandatory.
The main and most common part of TDD is unit testing. Unit
testing is a process and a set of techniques to divide an application into
smaller (small) units that are independent from each other and can work
isolated then test each unit to make sure it works as expected.
Unit testing works based on some principles. The first one
is breaking the application into small pieces which lets you examine their
working easily. The second principle is the fact that these units are isolated
and work independently from others. This isolation lets you change a unit
without having any effect on another unit.
Unit testing techniques test these pieces to see if each
piece works as expected for different situations and input data. In this case,
once you pass all tests, you can move on to the next stage in your development.
But the good point is the fact that if you change other elements and units of
the code then they would not break your existing code and if they do (which is
not surprisingly unexpected) then your existing tests will fail and alert you
about a problem.
So you can go back and forth and refractor your code without
breaking existing code and consistency of your code and this is the main reason
that many developers have chosen this as their primary process for development.
However, I cannot talk much about Test-Driven Development
and unit testing here and I should not, of course. But I just want to say that
there are various techniques for unit testing data layer, abstract code or web
services. There are also some well-documented patterns and practices on how to
write your code to make the unit testing process easier.
