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.