• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

author and the TDD experts, whats your opinion on BDD/TDD?

 
Ranch Hand
Posts: 1246
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is your experience with clients when doing BDD? Does your client like the idea? helping your client and you gather the requirement features quick an seamless? Does it feel burdensome when you code? with the extra work and etc.. etc..
Any hate/love relationship with BDD/TDD? cool stories?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all, I can't resist pointing out the history of the term Behavior-Driven Development. Here's what Dan North, the inventor of the term, says about its beginnings:

Dan North wrote:I started using the word “behaviour” in place of “test” in my dealings with TDD and found that not only did it seem to fit but also that a whole category of coaching questions magically dissolved. I now had answers to some of those TDD questions. What to call your test is easy – it’s a sentence describing the next behaviour in which you are interested. How much to test becomes moot – you can only describe so much behaviour in a single sentence. When a test fails, simply work through the process described above – either you introduced a bug, the behaviour moved, or the test is no longer relevant.

I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour- driven development.


In short, the original definition of BDD was more or less "TDD with a different vocabulary". In the recent years, BDD has grown to mean all sorts of things beyond the original idea. For instance, some people use it as a synonym for acceptance test-driven development (ATDD).

With that said, I've only seen one actual (non-technical) customer create executable examples directly in a computer-understandable format. That was almost 10 years ago when we gave our client a spreadsheet with some examples and she would expand on those examples, adding corner cases etc. In every other organization where I've seen specification by example in practice, the tools have been so obviously limiting and cumbersome that the real collaboration has happened with good ol' pen and paper and the team has encoded the examples from those conversations into various digital formats afterwards.

Having those concrete examples is pure awesome! Whether they're encoded into an executable format and can be run with a single command is somewhat secondary to me. A very nice bonus, if you will, but certainly not the beef.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic