Bdd - history and myths

@sebrose http://claysnow.co.uk

BDD -‐ (abbreviated) history and mythology

Seb Rose

Claysnow Limited

@sebrose

Wednesday, 18 March 15

http://claysnow.co.uk



READING LIST ALERTWednesday, 18 March 15




BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology.

It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

Dan North

http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business






@sebrose http://claysnow.co.ukWednesday, 18 March 15




Chris Matts working with Rohit Darji discover

“Pair Analysis”

2001





2002 (published 2005)





Chris Matts working with Sanela Hodzicformalise

“Break the model”

2003





At the end of 2003, I decided it was time to put my money – or at least my time – where my mouth was. I started writing a replacement for JUnit called JBehave, which removed any reference to testing and replaced it with a vocabulary built around verifying behaviour.

Dan North

http://dannorth.net/introducing-bdd/







Chris Matts and Dan North discuss the power of “should”

on a flight back from Agile 2004





Given/Then/When sees the light of day

abc.truemesh.com/archives/2004_11.html











Feature Injection & Real Options

2007




@sebrose http://claysnow.co.uk2012











2009 2011








Myth: It’s all about tools & automation





BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology.

It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

Dan North








having conversations is more important than

capturing conversations is more important than

automating conversations

Liz Keogh

http://lizkeogh.com/2014/01/22/using-bdd-with-legacy-systems/






@sebrose http://claysnow.co.ukhttp://lizkeogh.com/2011/03/04/step-away-from-the-tools/

Have enough conversations to know how to get started. Find out where the riskiest bits are, and where the system behaves unusually. Chat. Discuss. Discover. Work out how, and when, you’re going to get feedback on the work you’re about to do.

Then, and only then, reach for the tools.

Liz Keogh




http://lizkeogh.com/2011/03/04/step-away-from-the-tools/

http://lizkeogh.com/2011/03/04/step-away-from-the-tools/

@sebrose http://claysnow.co.ukhttps://leanpub.com/bdd




https://leanpub.com/bdd

https://leanpub.com/bdd


https://cucumber.pro/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool.html

When you do BDD/Specification by Example and Outside-in, regression tests fall out at the other end. They are a by-product of those activities. Testing isn't the activity itself.

Cucumber is first a foremost a collaboration too l t h a t a ims to b r i n g a common understanding to software teams - across roles.

Aslak Hellesøy







Myth: It matters what you call it




http://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/

What’s the difference between TDD, ATDD, BDD

and SbE?

They’re called

different things






"Behaviour-Driven Development (BDD) builds upon Test-Driven Development (TDD) by formalising the good habits of the best TDD practitioners."-- The Cucumber Book, 2011

Living documentation


The best TDD practitioners...

• Work from the outside-in, i.e. test-first

• Use examples to clarify their requirements

• Develop and use a ubiquitous language



The best BDD practitioners...

• Focus on value

• Discover examples collaboratively

• Create living documentation




Myth: We don’t need testers anymore










Myth: The more scenarios, the better





“I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a

given level of confidence ...

“I suspect this level of confidence is high compared to industry standards”

http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565








Myth: The scenarios should include all details





Imperative Declarative

Keep it Focussed: Avoid incidental details





Feature: Sign up Scenario: New user redirected to their own page Given I am not logged in And I visit the homepage And I follow "Sign up" And I fill in "Username" with "Matt" And I fill in "Password" with "password" And I fill in "Confirm password" with "password" When I press "Sign up" Then I should be on my feeds page And I should see "Hello, Matt"





Feature: Sign up Scenario: New user redirected to their own page When I sign up for a new account

Then I should be taken to my feeds pageAnd I should see a greeting message





Imperative vs Declarative Style

Feature: The entire system This feature illustrates what can happen when you take the declarative style too far.

Scenario: It works When I use the system Then it should work perfectly





Imperative vs Declarative Style

Feature: Sign up Scenario: New user redirected to their own page Given I am not logged in And I visit the homepage And I follow "Sign up" And I fill in "Username" with "Matt" And I fill in "Password" with "password" And I fill in "Confirm password" with "password" And I press "Sign up" Then I should be on my feeds page And I should see "Hello, Matt"

Feature: Sign up Scenario: New user redirected to their own page When I sign up for a new account Then I should be taken to my feeds page And I should see a greeting message





(A great blog post on this subject by Dan North)

http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/

Whose domain is it anyway?







Myth: You don’t need development skills to write scenarios

This page unintentionally blank.





Seb Rose

Twi6er: @sebrose

Blog: www.claysnow.co.uk

E-‐mail: [email protected]

Availa

ble No

w




Bdd - history and myths

Technology

sebrose http

dan northhttp

ukchris matts

delivery of working

agile methodology

tested software

welldefined outputs

ukhaving conversations