I have not seen consensus, and I think TDD (test before) overall is not a good idea. Without reasoning that is only an opinion, but others have argued already extensively. See the contents of the links sent in this thread.
I wondered where the TDD focus came from in some communities. For ruby you can read about it here: http://codingitwrong.com/2017/01/14/why-rubyists-test.html
For another small but good old rant read http://dlinsin.blogspot.nl/2008/06/nothing-wrong-with-tdd-right.html
TDD- what is this supposed to deliver again? Oh yeah, that's right, code quality....
"This code has been tested...."
The problem is of course that even the most simple program has so many possible states that a
computer the size of the universe composed of gates the size of atoms which in turn switch states
at the speed of light couldn't compute all the possible states of that program so that you can say
you've tested it.
So what does TDD do? Why it tests the subset of data that the programmer determines, through
experience and intuition, are likely to to cause trouble - corner cases, pathological input etc.
And this is different from what programmers have always done ... how again? In know I should
know the answer to this b/c TDD priests have been preaching for years now, but I just can't
The fact is, TDD promises something undeliverable- throughly tested code. What it relies
on is exactly what it denies the sufficiency of - a programmer's analytic understanding of
the code and ability to understand, without testing, what a program will do. That understanding
is just how the data that is unit tested is selected from the universe of data which could be
But as I said, this is just what programmers have always done.
Like it or not, the best and ONLY reason programs work as expected is because there's an
experienced developer sitting there who understands how it works.
I know there's a level of management that hates to hear that, because it immediately implies
a dependency upon individual developers. TDD found its most sympathetic hearing in the
corner offices because it promises to increase the interchangeability of developers. A best
interpretation is TDD attempts to capture best practices of good developers, and a more realistic
interpretation is it churns out a deaf mockery of those practices and imposes a leaden, mechanical
and pointless exercise of busy work and wasted time.
TDD is a kind of false assurance or hand-holding for people who are afraid of their code base.
At some point, corporations will learn that there IS a talent market worth paying a lot of money
to participate in, but its not at the CEO level- it's at the level of the individual developer.
Writing code is not flipping burgers and the interchangeable "labor" model that applies
to McDonald's isn't going to fly in IT.