

TDD is Behavior Specification - kevingoslar
http://blog.originate.com/blog/2014/02/20/tdd-is-bs

======
JanezStupar
I had a very similar outlook.

However since I have been doing a lot of development for cloud platforms
(Google App Engine for instance), I have realized that without tests you don't
really have a sane way of debugging and verifying your code.

And since I always write a lot of code during my work (testing stuff out in
python shell) I have realized how wasteful my previous approach was.

If I had written that code into a file and added a couple of assertions I
would have a nice test suite.

However I still believe that on should not overdo tests from the get go. Write
the tests for common cases, then add regression tests as bugs pop up here and
there.

That gives the best ROI IMHO.

Edit: I have to confess that indeed I have read the TLDR; then the first
paragraph and then I was already writing a comment here.

For the record I think that cargo cultists are going to be cargo culting no
matter how we call this or that.

~~~
bentona
If you actually read the article, I think you'll find yourself on the same
page as the author.

------
JesseObrien
> Asking people to write tests before they write code is like asking them to
> test-drive a new car before it even exists. This isn’t possible.

This is an incredibly bad analogy that really doesn't stand up. You _can_
write tests before you write the implementation of them, to define how you
want the end result of your program's interfaces to look. The rest of the
article arguing the semantics behind calling them _tests_ or _specifications_
doesn't add anything but confusion to the testing discussion.

This:

> Calling tests specifications makes the concept more intuitively available in
> several ways.

Is entirely subjective.

~~~
kevingoslar
The point of the article is that you actually write specifications, and just
call them "tests". Which is confusing. "Testing" means measuring or checking
the quality of something.

~~~
mitchty
Well you're testing your specifications that you write later.

I think this is just semantic fencing to be honest.

------
charlieflowers
Isn't this basically what Dan North and Chelimsky said when they started the
BDD movement? Is TFA intended to be merely a restatement of the BDD concept
from circa 2007? Or is it saying something more that I overlooked?

~~~
dragonwriter
No, BDD was an adaptation of TDD to be something different, this is just an
explanation of TDD to people who don't understand what TDD _is_ , and don't
understand how you can test code before you build it (which, obviously, TDD
doesn't do -- it builds executable specifications for what a unit of code will
do before its built.)

BDD is similar, but focuses on higher levels units of change that TDD does,
and focuses on accessibility of the specifications to customers / analysts.

~~~
charlieflowers
Well, I'm not trying to snark ... I just don't see the distinction. When BDD
first came out, it was based on the premise that, yes, we're really just doing
the same thing as TDD, but we're using better words. We use "spec" instead of
"test," for example. And merely the act of using more precise words has a deep
effect on how we think, and therefore that alone is worthy enough of a basis
to launch a new movement called "BDD."

I liked TFA for its clarity and I believe it is accurate. But it still feels
to me like it articulates the same thing I read when BDD was new. I wonder if
possibly the author has rediscovered, independently, the same thing that
motivated the launch of BDD in the first place.

~~~
dragonwriter
> When BDD first came out, it was based on the premise that, yes, we're really
> just doing the same thing as TDD, but we're using better words. We use
> "spec" instead of "test," for example.

BDD is a higher level framework (focussed on acceptance test rather than unit
test) and addresses relationships in a broader scope (customer to dev team)
than TDD tends to. Its not just a rephrasing, its a further development.

BDD also focussed on _how_ tests should be _expressed_ based on the
combination idea of being executable specs and the idea that that
analysts/customers should be involved in, at least, reviewing them.

So, some of the things in the article here might be related to the thinking at
the roots of BDD (heck, it even uses the word "behavior driven design"), but
its making points about TDD that are outside of what BDD is focussed on.

------
joevandyk
In a nutshell, he's saying to call it "specification driven development",
since you are writing specifications for the code before it exists.

~~~
codr
Which seems useless to me.. it's still the same idea, the same thing.

~~~
kevingoslar
Yeah, but using the right terminology makes the concept more self-describing
and therefore more accessible.

~~~
JanezStupar
I was around when the term TDD first appeared. And I don't think that
originally it meant anything more than what you are proposing.

But then some dudes came along and said: "This is awesome, lets make it
better!"

And before one could blink, a concept of 100% coverage was born. From there on
everything went full retard.

~~~
jarhart
I completely agree that TDD originally meant that, and still does. The problem
is too many developers don't bother to learn what TDD really means and
immediately think of it as a testing methodology because the first word is
"test". Maybe changing the language can change the focus to where it was
supposed to be from the beginning.

------
jarhart
I'm often frustrated with developers looking at the term "test-driven
development", focusing on the word "test", and thinking of TDD as a testing
process instead of a development process. The BDD movement made some progress
on this front, but it still seems to be a problem. Maybe calling it
"specification-driven development" is the next step.

------
a3voices
TDD is a great way to take the fun out of software development.

~~~
mpweiher
Au contraire: it makes software development a lot _more_ fun, at least in my
experience.

However, it back-loads the fun. With usual coding, the fun part is at the very
start, you get to see something very quickly. But then the debugging starts,
at least if there is any complexity involved, and the fun quickly wears off.
You'll figure it out eventually, but by that time you are worn and tired.

With TDD, the not-quite-as-much fun part is front-loaded: you have to really
think about what you are trying to do, almost always start with non-GUI code
so there are no quick-wins to show off. However, once the you get all the
tests to pass you are done and can check in and/or go home on a high note.

