TDD is Behavior Specification

http://blog.originate.com/blog/2014/02/20/tdd-is-bs

by kevingoslar • 12 years ago

15 19 12 years ago

blog.originate.com

a3voices• 12 years ago

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

mpweiher• 12 years ago

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.

kevingoslar3• 12 years ago

If you ever had to hunt down a bug for 2 days in an untested code base, you know that testing brings back the fun of coding. Actually, writing tests is fun as well if it is done with the right levels of abstraction, and if you follow the red-green-cycles.

JanezStupar2• 12 years ago

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• 12 years ago

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

joevandyk• 12 years ago

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

codr• 12 years ago

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

kevingoslar3• 12 years ago

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

lliamander• 12 years ago

I think there is actually a meaningful distinction between the two. "Specification Driven Development" refers to the artifact you are creating; whereas "Test Driven Development" refers to the activity you are using that specification for. You are right that in the case of TDD as typically practiced, it doesn't really matter since the specifications are only used to conduct tests. However, if you treat the specifications as _data_ rather than code, you greatly increase kinds of verification activities you can with those specifications; such as theorem proving, model checking, test generation, code contracts, and documentation. See the talk "Beyond Contracts: An Exploration into Unified Specifications" -- (http://www.infoq.com/presentations/Unified-Specifications-Cl...) for more on this idea.

JesseObrien• 12 years ago

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.

kevingoslar3• 12 years ago

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• 12 years ago

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

I think this is just semantic fencing to be honest.

jarhart2• 12 years ago

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.

charlieflowers2• 12 years ago

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?

dragonwriter2• 12 years ago

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.

charlieflowers2• 12 years ago

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.

TDD is Behavior Specification

Related Stories