4. Don’t be fooled by BDD
Reasoned by:
Q&A from BBDD talk
http://seleniumcamp.com/talk/better-bullshit-driven-development/
5. Don’t be fooled by BDD
Inspired by:
D. Zharii comment at “TDD vs BDD: what the difference?” (ru, en)
Dan North’s “Introducing BDD”, March 2006 (en)
Dan North’s “Introducing RBehave”, June 2007 (en)
Dan North’s “BDD is like TDD if”, May 2012 (en)
Liz Keogh’s “Translating TDD to BDD”, November 2009 (en)
Liz Keogh’s “Showcasing the language of BDD”, May 2012 (en)
Wiki’s “Behaviour-driven development” (en)
yashaka's:) experience of fighting with customers about using BDD at incorrect scopes :)
10. BDD is
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
?
11. BDD is
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
12. BDD is
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
13. BDD is
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
14. BDD is
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
15. BDD is
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
16. BDD is
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
17. BDD is
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
18. BDD is
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
19. BDD is outside-in
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
20. BDD is outside-in
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
any mention about
Automation Engineers?
21. BDD is outside-in
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
any mention about
Automation Engineers?
so why do
“hammering nails with a microscope”?
24. Once upon a time… one TDD coach…
faced problems in his trainings…
Dan North: “Introducing BDD”, March 2006
“Programmers wanted to know where to start, what to test and what not to test, how
much to test in one go, what to call their tests, and how to understand why a test
fails.” (c)
25. So he thought about…
“Test method names should be sentences” (c)
giving at least
some docs to devs
public class DiasporaBoardComponentTest {
...
public void testSharesMessage() {
...
}
}
Dan North: “Introducing BDD”, March 2006
26. So he thought about…
“Test method names should be sentences” (c)
giving at least
some docs to devs
public class DiasporaBoardComponentTest {
...
public void testSharesMessage() {
...
}
}
Dan North: “Introducing BDD”, March 2006
side note: examples were prepared in the “acceptance” context
instead of the “unit” context, as in the original article…
27. So he thought about…
“Test method names should be sentences” (c)
giving at least
some docs to devs
public class DiasporaBoardComponentTest {
...
public void testSharesMessage() {
...
}
}
Dan North: “Introducing BDD”, March 2006
28. So he thought about…
…in the language of the business domain
so starts to make more sense to other stakeholders (BA, Test E.)
Dan North: “Introducing BDD”, March 2006
public class DiasporaStreamTest {
...
public void testSharesPost() {
...
}
}
29. So he thought about…
…with “should” instead of “test”
so starts to make more sense to other stakeholders (BA, Test E.)
Dan North: “Introducing BDD”, March 2006
public class DiasporaStreamTest {
...
public void shouldSharePost() {
...
}
}
30. So he thought about…
…with “should” instead of “test”
“… implicitly allows … to challenge …: “Should it? Really?” .. easier to decide whether a
test is failing due to a bug … or … because … previous assumptions about … behaviour
are now incorrect.” (c)
Dan North: “Introducing BDD”, March 2006
public class DiasporaStreamTest {
...
public void shouldSharePost() {
...
}
}
31. So he thought about…
…“Behaviour” is a more useful word than “test” (c)
Dan North: “Introducing BDD”, March 2006
TBDD = TestBehaviour-driven development
32. So he thought about…
…creating tools to help "to be in behaviour context”
Dan North: “Introducing BDD”, March 2006
early: JBehave, RBehave (then “was merged” to RSpec)
late: Cucumber, etc.
33. So he thought about…
…creating tools to help "to be in behaviour context"
Ruby + RSpec example
describe 'Diaspora stream' do
it 'should share post' do
...
end
end
Dan North: “Introducing BDD”, March 2006
34. So he thought about…
focus on business value...
"What’s the next most important thing the system doesn’t do?" (c)
describe 'Diaspora stream' do
it 'should share post' do
...
end
it 'should delete post' do
# to be implemented
end
end
Dan North: “Introducing BDD”, March 2006
35. So he thought about…
share all this stuff with BA, testers... that's actually same thing - specifications
describe 'Diaspora stream' do
it 'should share post'
it 'should edit post'
it 'should hide post'
it 'should delete post'
...
end
Dan North: “Introducing BDD”, March 2006
36. So he thought about…
(being inspired by domain-driven design ideas)
define "ubiquitous language" for the "analysis" itself
Dan North: “Introducing BDD”, March 2006
As a [X] I want [Y] so that [Z]
Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.
37. So he thought about…
(being inspired by domain-driven design ideas)
define "ubiquitous language" for the "analysis" itself
Dan North: “Introducing BDD”, March 2006
As a [X] I want [Y] so that [Z]
Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.
where (c)
Y is some feature,
Z is the benefit or value of the feature,
and X is the person (or role) who will benefit.
38. So he thought about…
(being inspired by domain-driven design ideas)
define "ubiquitous language" for the "analysis" itself
Dan North: “Introducing BDD”, March 2006
As a [X] I want [Y] so that [Z]
Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.
39. So he thought about…
Acceptance criteria should be executable (c)
Dan North: “Introducing BDD”, March 2006
Ruby + early RBehave example
Dan North: “Introducing RBehave”, June 2007
Story 'share post',
%(As a diaspora user
I want to share post to the stream
So that I keep my subscribers updated with all my news) do
Scenario 'new post can be added to user stream' do
Given 'user logged in with credentials:', 'yashaka', 'secret'
When 'shared new post:', 'will give a talk about BDD today'
Then 'user stream should be updated with a new top post:', 'will give a
talk about BDD today'
end
Scenario 'subscriber stream is updated with the new user post'
...
end
40. Story 'share post',
%(As a diaspora user
I want to share post to the stream
So that I keep my subscribers updated with all my news) do
Scenario 'new post can be added to user stream' do
Given 'user logged with credentials:', 'yashaka', 'secret' do |user, passw|
diaspora.login_page.open().sign_in(user, passw)
end
When 'shared new post:', 'will give a talk about BDD today' do |message|
diaspora.stream.new_post.start().write(message).share()
end
Then 'user stream should be updated with a new top post:', 'will give a talk
about BDD today' do |message|
diaspora.stream.post(0).should_be(message)
end
end
Scenario 'subscriber stream is updated with the new user post' do
...
end
end
Ruby + early RBehave example
41. Finally he invented…
Dan North: “Introducing BDD”, March 2006
Dan North: "How to sell BDD to the business", November 2009:
"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." (c)
42. Remember? outside-in BDD
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
any mention about
Automation Engineers?
43. Remember? outside-in BDD
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
any mention about
Automation Engineers?
notice emphasising BA terminology?
44. Remember? outside-in BDD
TDD
tests first
written by devs
with tests
as documentation
as behaviours
focused on business
as specification
i.e. provided from BA side
a tool to define unclear reqs
in ubiquitous language
discussed between all stakeholders
(BA, Test, Dev, etc.)
any mention about
Automation Engineers?
notice emphasising BA terminology?
moreover, BDD is NOT about Testing!
45. Testing...
Wiki's "Software Testing"
"Software testing is an investigation conducted to provide stakeholders with
information about the quality of the product or service under test." (c)
46. BDD...
is about "investigation conducted by stakeholders to figure out what the product
SHOULD be" (c)
Liz Keogh’s “Showcasing the language of BDD”, May 2012
47. Testing...
"we assume that we don’t know what we’re doing (and probably don’t know that we
don’t know)" (c)
Liz Keogh’s “Showcasing the language of BDD”, May 2012
BDD...
"imply that you know what you’re doing and just want to make sure you’ve done it" (c)
48. So...
1. BDD starts earlier than Testing Product can even become possible…
2. BDD is completely not about "Automating Regression by testers/automation
engineers". Because once we already have implementation - we missed the train.
There are no more of those main problems that BDD was created to solve.
49. Given the train is missed
When trying to catch the train with automation coverage
And as usual lacking time
Then why to use BDD tools –
often heavy frameworks
tuned for BA that is already not relevant ?
52. Cucumber-jvm
@defaults
Feature: Diaspora
Scenario: Share message
Given I signed in from login page with credentials: 'yashaka', 'secret'
When I publish new post: 'will give a BDD talk today'
Then I should see new post 'will give a BDD talk today' in the top of
stream
53. Cucumber-jvm
public class DiasporaStepdefs {
LoginPage loginPage = new LoginPage();
NewPost newPost = new NewPost();
Stream stream = new Stream();
@Given("^I signed in from login page with credentials: '(.+)', '(.+)'$")
public void
I_signed_in_from_login_page_with_credentials_selenide_yagniyagni(String
username, String password) {
loginPage.open();
loginPage.signIn(username, password);
}
...
54. Cucumber-jvm
...
@When("^I publish new post: '(.+)'$")
public void I_publish_new_post_Selenide_is_released_(String text) {
newPost.start();
newPost.write(text);
newPost.share();
}
@Then("^I should see new post '(.+)' in the top of stream$")
public void
I_should_see_new_post_Selenide_is_released_in_the_top_of_stream(String text)
{
stream.shouldHavePostWithText(0, text);
}
}
56. Spock + Fluent PageObject + Allure @steps + One Entry Point
public class DiasporaStreamTest extends Specification {
def "should share post"() {
given: "user logged in"
app.loginPage().open().signIn("yashaka","secret")
when: "shared new post"
app.newPost().start().write("will give a BDD talk today").share()
then: "new post should appear in the top of the stream"
app.stream().post(0).shouldBe("will give a BDD talk today")
}
}
57. Spock + Fluent PageObject + Allure @steps + One Entry Point
public class DiasporaStreamTest extends Specification {
def "should share post"() {
given:
app.loginPage().open().signIn("yashaka","secret")
when:
app.newPost().start().write("will give a BDD talk today").share()
then:
app.stream().post(0).shouldBe("will give a BDD talk today")
}
}
or even simpler if desired
59. JUnit + Fluent PageObject + Allure @steps + Gherkined One Entry Point
public class DiasporaStreamTest extends GherkinTest {
@Test
public void shouldSharePost() {
GIVEN("user logged in")
.loginPage().open().signIn("yashaka","secret");
WHEN("shared new post")
.newPost().start().write("will give a BDD talk today").share();
THEN("new post should appear in the top of the stream")
.stream().post(0).shouldBe("will give a BDD talk today");
}
}
60. JUnit + Fluent PageObject + Allure @steps + Gherkined One Entry Point
public class DiasporaStreamTest extends GherkinTest {
@Test
public void shouldSharePost() {
GIVEN().loginPage().open().signIn("yashaka","secret");
WHEN().newPost().start().write("will give a BDD talk today").share();
THEN().stream().post(0).shouldBe("will give a BDD talk today");
}
}
or even simpler if desired
61. Summary
GIVEN no outside-in:
no BA writing Gherkin
AND no Devs writing tests before implementation
AND automation engineers writing tests after
WHEN
xUnit + static Java
AND Fluent PageObjects with Allure readable @Steps
AND Gherkin style of One Entry Point (aka Application Manager)
THEN
"not BA" pros of BDD can be achieved much easier and faster
62. Summary
GIVEN no outside-in:
no BA writing Gherkin
AND no Devs writing tests before implementation
AND automation engineers writing tests after
WHEN
xUnit + static Java
AND Fluent PageObjects with Allure readable @Steps
AND Gherkin style of One Entry Point (aka Application Manager)
THEN
"not BA" pros of BDD can be achieved much easier and faster
KISS: classic static Java
and simple yet powerful Junit/TestNg (parallelisation, etc.)
need additional Gherkin support
but impl is few simple no-magic lines of code
with ability to match fluently the one entry point
63. Summary
GIVEN no outside-in:
no BA writing Gherkin
AND no Devs writing tests before implementation
AND automation engineers writing tests after
WHEN
Spock + dynamic Groovy
AND Fluent PageObjects with Allure readable @Steps
AND One Entry Point (aka Application Manager)
THEN
"not BA" pros of BDD can be achieved much easier and faster
64. Summary
GIVEN no outside-in:
no BA writing Gherkin
AND no Devs writing tests before implementation
AND automation engineers writing tests after
WHEN
Spock + dynamic Groovy
AND Fluent PageObjects with Allure readable @Steps
AND One Entry Point (aka Application Manager)
THEN
"not BA" pros of BDD can be achieved much easier and faster
for some newcomers – too dynamic => prone to hardly debuggable errors
but less "fluent"
less parallel tests support
test names as strings with spaces
out of the box gherkin
65. pseudo-BDD with
xUnit/Spock, Fluent PageObjects, Allure @Steps, “Gherkined" One Entry Point
• all-powerful programming language over textual-pseudo-language
• full IDE support (autocompletion, auto-generate, etc.)
• 1 abstraction layer less => simpler and faster in implementation
• still fully readable and with pretty good reports
• newcomers friendly
• Just One Entry Point to all Application Model
• structured with granular Fluent PageObjects => easier to learn&use via
autocompletion