Test Driven Development

Blog > Test Driven Development

Software Testing is a method to check whether the actual software product matches expected requirements and to ensure that the software product is defect-free.

It involves the execution of software/system components using manual or automated tools to evaluate one or more properties of interest. The purpose of software testing is to identify errors, gaps, or missing requirements in contrast to actual requirements.


Test-driven development (TDD), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.


Uncle Bob describes TDD with three rules:

  • You are not allowed to write any production code unless it is to make a failing unit test pass.
  • You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  • You are not allowed to write any more production code than is sufficient to pass the one failing unit test.


Understanding of TDD


TDD completely reverses traditional development. When you first start implementing a new feature, the first question you will ask is whether the current design is the best possible design that allows you to implement that functionality.


If so, you proceed via a TFD (Test-First Development) approach. If not, it is rearranged locally to replace the part of the design affected by the new feature, allowing you to add this feature as easily as possible. As a result, not only you will always improve the quality of your design, it will also make it easier for you to work in the future.


As a young test engineer, I am aware that I talked too much, I will keep it a little short for you as much as I like to talk.

To summarize briefly,

Test-driven development (TDD) is a development technique in which you must write a failed test before writing a new functional code.

TDD is rapidly being adopted by agile software developers for the development of application source code, and even by Agile DBAs for database development.

TDD should be seen as a complement to Agile Model Driven Development (AMDD) approaches and the two can and should be used together.