Say I am working on a React app, in Agile methodology. I pick up a story. Do the dev work sans unit tests. Push it to the testers for picking up when they are ready. In the meanwhile, I start writing unit tests for my code.
That's the new proposal my team's making than the usual TDD or unit tests + feature work and then testing.

Testers get their hands on the changes early, helps with sprint progress
If there is a bug, there will be a bit of back and forth between devs and QA hampering the sprint progress.
Reviewing PRs will get hard as we can't tell what the feature is doing without looking at the tests.
Since the feature is "working fine" as per them, they might take shortcuts to finish up with testing.

The above points are not sufficient for my team, they insist on faster delivery. There have been bugs that would have been caught if it was unit tested. But thats not cutting it.
Are there any better arguments for dev + unit tests > qa instead of dev > qa > unit tests?

1 Answer 1


Oh, that's a long one.

Let's take two points of view:

  • Pragmatic POV:

they insist on faster delivery

Saying that TDD would decrease delivery speed is not necessarily true.

If you search for studies on this, you will find a mixed bag of conclusions, highly dependable on the research methodology itself - this is the case because the code you write through TDD is not the same code you write with TLD (Test Last Development).

Thus, it's a false dichotomy - it depends on each particular context.

enter image description here

  • Ethical POV:

For a longer discussion on this, I suggest watching Bob Martin's Craftsman's Oath talk. In a nutshell, the argument is that developers have the duty to his/her of demonstrating what capabilities of the software and the duty to his/her developer colleagues to ensure the software is kept in a state that they can work.

And these two duties can only be achieved* through TDD (or maybe even Test-Commit-Revert - TCR as Kent Beck shows).

The first because TDD/TCR limits the developer to only make progress in the production code based on one demonstratable behavior - if more behavior is added without a previous failing test, it's not TDD/TCR. Bugs will exist, for sure - but not bugs because of a misunderstanding between the programmer's intent and what he/she codes, because he/she coded the behavior twice (as a specialized test and as generic production code).

The second because only through TDD you can ensure you can safely refactor. Without the limitation above, you may never know if there is some behavior not demonstrated by tests. Without this certainty, all refactoring work is in the hope nothing will unnoticeably break. Line coverage and mutation coverage analysis could help, but they are not as complete as the TDD limitation.

* "can only be achieved": A necessary condition, not a sufficient condition.

If these two points are not relevant for your context, then TDD/TCR loses most of its reason to be.

If you want to have fast delivery, you may want to consider Continous Delivery. The idea is to keep your software always in a deliverable state. No hidden long-living branches, no half-done features (meaning we are not sure if it works as intended), etc. CD is a consequence of a broad set of practices which include TDD, Continous Integration, etc. Dave Farley Youtube channel and book can give you a good introduction.

  • Will the developers slow down when first learning TDD? For sure.
  • Will the developers feel frustrated when first learning TDD? For sure.
  • Is there anything worth learning that doesn't make you slow down and frustrated during the learning process? No.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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