My question was more a general question about the purpose of test-driven development, or its intended usefulness.

I know that test-driven development is a style of development where you write tests before you write code. I can see how this would help structure a person's thoughts with regards to what they need to code. The question is this:

Is the purpose of test-driven development purely focused on improving the quality of code, or is it more about spending time up front with the intention of saving time in the long run?


As a short answer: it is about both.

You will certainly have developers more conscious/accountable for their code if at the unit level it is marked pass/fail. Also, just like you said, test early, it will save you time later.

PROD defects are much much more costly than defects found earlier.


Test Driven Development, aka TDD, as a process of writing your unit tests prior to your development. This helps the developer in several ways, the biggest advantage is, in my opinion, the developer's mindset when starting the task.


For example, your developer is starting out on a new task. They get their requirements, writes their code and then their unit tests. While writing his test they notice they missed a scenario in the code and has to refactor the code. After a couple hours of refactoring code that they already spent a couple of hours to write, they feel like they are in a position to run the tests again.

After a couple of hours of refactoring to make it pass the unit testing, the code is finally complete. The code is sent to QA and defects are found. The code is fixed, unit tests are added into the code and code is sent to QA. These steps are repeated until the code is considered acceptable.


The developers gets their requirements. The developers discusses with QA (hopefully) the planned unit testing. The unit tests are written and reviewed. The developer builds the code in order to be passed by the unit tests. The developer continues to build and refactor code until all unit tests are passed.

The code is sent to QA, QA finds defects and defects are resolved. The developer writes further unit tests for the defects that are found and once the code passes all unit tests it goes back to QA. This process repeats until the code is considered acceptable.

The Benefits

The primary benefit is, hopefully, the reduction in amount of code written and refactoring. The focus of the developers at the beginning of the project is what is the ultimate goal of this code instead of where do I start to write this code. This ensures that the requirements are clear, there is little doubt in the developer's mind as to what is supposed to happen and less gathering of requirements while in the middle of development, causing more and more wasted time for the developers.

Does it lead to better quality code? Yes and no. It will usually give better quality code on the first release to QA. This typically will lead to overall better code as defect fixes are typically hastily written and will a lot of times cause other issues. No in the sense that it might still lead to poor quality code if the developer's requirements were vague to begin with.

The main benefit, in my opinion, is extremely thorough unit testing. This will lead to much cleaner code in the long term when someone else comes in to refactor the original developer's code because there is a change.

How does it pertain to QA?

Expect nothing better than normal development. Don't rely on their unit testing and make sure that you do your job as thorough as possible. However, do attempt to discuss the developer's testing methods with them before they write a line of code. This will hopefully ensure that they cover more scenarios with their unit testing and (hopefully) give you a better product to start testing with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.