
TDD is a feedback tool, not a religion - th3james
http://th3james.github.io/blog/2014/05/17/tdd-is-a-feedback-tool/
======
mkal_tsr
* TDD is not the end-all-be-all

* BDD is not the end-all-be-all

* Waterfall/XP/Scrum/Kanban/next-year's-methodolgy-buzzword is not the end-all-be-all

* An individual language or framework is not the end-all-be-all.

I don't know what happened, but lately it seems like every freaking blog post
related to technology or start-ups debates that X (not Y) is the holy-grail of
Z-topic.

There is no holy-grail, only context. Use your expanding knowledge and tool-
set along with the context of the situation/task and form an appropriate
solution.

~~~
jacques_chester
Would you say that there's no "Silver Bullet"?

~~~
mkal_tsr
If we admit there is no Silver Bullet, how will we _ever_ generate link-baity
headlines about programming methodologies to attempt to validate my beliefs as
correct instead of being open-minded about different approaches? ;-)

------
cuillevel3
Nice blog post.

The internet is an echo chamber.

I'm happy DHHs keynote brought some sense back into the discussion. Fowlers
and Becks comments are great, too.

------
deckiedan
Not sure if I trust this argument, before we can really discuss it:

1) Write test to prove TDD exists 2) Write test to prove TDD is a tool 3)
Write test to prove TDD gives feedback given good input 4) Write test to prove
TDD gives feedback given bad input 5) Write test to prove TDD gives feedback
given no input 6) Write test to prove TDD gives feedback given mulitple
input(s) 7) Write tests to define how a religion should respond to certain
criteria. 8) Write test to prove TDD when try to be used as a religion fails.

9) Mock TDD, in a friendly kind of way. :-)

Yes, there are good points and bad points to TDD. I'm glad the concepts,
debates, and frameworks exist. Even if I don't follow them 100%, they do help
me to think about a lot of that stuff in projects I design. In everything,
moderation. Currently I prefer thinking, tinkering, REPL/playing design until
I have a basic structure working, and I can see how I want it all to work, and
then write tests afterwards, fixing any bugs that the tests reveal.
Experiment-Driven-Design, Test-Driven-Maintenance. This probably only works
for small projects, though.

------
gaelow
Can't disagree, but computer science is in serious need of less but better and
well known, highly reliable software development standards.

Something universal that makes us confident enough to say: If you follow this
process you'll ALWAYS get the work done in the predicted time frame, and this
will not happen:
[http://ykyuen.files.wordpress.com/2010/02/howprojectreallywo...](http://ykyuen.files.wordpress.com/2010/02/howprojectreallyworks1.jpg)

One of my software engineering professors used to comment often that if
architects and structural engineers didn't had those procedures, 9 out of 10
bridges would collapse and there would be no way to guarantee the remaining
10% would be fit to handle x amount of traffic on any given day.

Software engineering is a new science, not thousands of years old like bridge
building, so we are taken our first baby steps towards that kind of efficiency
and reliability. TDD is one of them.

------
claudiusd
TDD forces you to describe what your code is supposed to do rather than how it
works (which is common when testing after the fact). When your tests describe
what your code is supposed to do, they will forever guarantee that your
program does not lose any functionality or end-user value. Even after doing
significant refactoring, you can be confident that your code still satisfies
all of the requirements you've forgotten about.

While your TDD methodology may be flawed, this focus on end-user value has
proved itself time and time again. Discussions like this one only play into
DHH's flawed logic and do the programming public a disservice by pretending
like there's some argument about whether TDD is effective or not.

TDD works great if you do it right. A TDD methodology may or may not work
depending on the circumstance. Choose the methodology that's most appropriate
for the situation and you will have success.

~~~
Codhisattva
That's the best point made yet - use TDD only if it's appropriate.

~~~
wpietri
I think there are a lot of things whose appropriateness is hard to know unless
you have some experience with it. That's especially true where you're trading
short-term costs for long-term wins.

For example, think of restaurant hygiene. Safe food handling is hard work. And
if you skimp on it, it's easy to say, "Hey, doing X isn't really necessary;
nothing bad happened."

For me, TDD is similar, in that the benefits mainly come later, when you have
a sizable code base that you can make big changes to without fear. I agree
people should use it when appropriate; there are definitely times when I don't
bother. But I'm concerned that people who haven't experienced success (and
failure) with TDD will have poor intuition for when it's appropriate.

~~~
greenyoda
_" For me, TDD is similar, in that the benefits mainly come later, when you
have a sizable code base that you can make big changes to without fear."_

The ability to refactor without fear comes from having adequate test coverage.
Whether you write the tests before you write the code (TDD) or after the code
is completed doesn't seem to affect your ability to refactor at a later date.

~~~
wpietri
For me, it definitely affects the quality of the tests. Once I've written the
production code, I know how it works, so its faults are harder for me to see.
I also find it's easier to leave coverage gaps. I think I could get some of
the same benefit by bringing in somebody else to review tests without looking
at the production implementation, but I haven't tried.

The other thing I think TDD gets for me is cleaner API design, because my
orientation begins (and mainly stays) _outside_ the thing I'm working on. And
cleaner design definitely makes refactoring easier.

Of course, if people have tried it both ways and feel they are getting the
same results with some other technique, that's great. But one can only measure
long-term maintainability by maintaining a code base for a while, so I think
regardless my point on needing experience to judge appropriateness of TDD
stands.

------
Codhisattva
DHH's use of hyperbolic metaphors discredits the point he's trying to make. He
has no factual argument so he exaggerates small points and maligns
practitioners. It's sad.

------
trhway
it doesn't matter what a something really is when its zealots come.

------
dominotw
Martin Fowler is still relevant?

