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.
I think this is just semantic fencing to be honest.
BDD is similar, but focuses on higher levels units of change that TDD does, and focuses on accessibility of the specifications to customers / analysts.
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.
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.
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.
