Iakiv Kramarenko - Don't be fooled with BDD, automation engineer

@yashaka
Don’t be fooled with BDD,
automation engineer;)

@yashaka
seleniumcourses.com
About

Don’t be fooled by BDD
Reasoned by:
Q&A from BBDD talk
http://seleniumcamp.com/talk/better-bullshit-driven-development/

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 ﬁghting with customers about using BDD at incorrect scopes :)

Plan
Preface: BDD?
BDD History
Cucumber-like BDD tools
“xUnit restyled to BDD” tools
xUnit tools styled as BDD
Summary
Q&A

Plan
Preface: BDD?
BDD History
Summary
Q&A
now
past
Tools retrospective

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.)
?

BDD is
TDD
tests ﬁrst
written by devs
with tests
as documentation
as behaviours
focused on business
as speciﬁcation

BDD is outside-in
TDD
tests ﬁrst
written by devs
with tests
as documentation
as behaviours
focused on business
as speciﬁcation

BDD is outside-in
TDD
tests ﬁrst
written by devs
with tests
as documentation
as behaviours
focused on business
as speciﬁcation
any mention about
Automation Engineers?

BDD is outside-in
TDD
tests ﬁrst
written by devs
with tests
as documentation
as behaviours
focused on business
as speciﬁcation
any mention about
so why do
“hammering nails with a microscope”?

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)

So he thought about…
“Test method names should be sentences” (c)
giving at least
some docs to devs
public class DiasporaBoardComponentTest { 
 
... 
public void testSharesMessage() { 
... 
} 
}

“Test method names should be sentences” (c)
giving at least
some docs to devs
public class DiasporaBoardComponentTest { 
 
... 
public void testSharesMessage() { 
... 
} 
}
side note: examples were prepared in the “acceptance” context
instead of the “unit” context, as in the original article…

…in the language of the business domain
so starts to make more sense to other stakeholders (BA, Test E.)
public class DiasporaStreamTest { 
 
... 
public void testSharesPost() { 
... 
} 
}

…with “should” instead of “test”
so starts to make more sense to other stakeholders (BA, Test E.)
public class DiasporaStreamTest {  
 
... 
public void shouldSharePost() { 
... 
} 
}

…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)
public class DiasporaStreamTest {  
 
... 
... 
} 
}

…“Behaviour” is a more useful word than “test” (c)
TBDD = TestBehaviour-driven development

…creating tools to help "to be in behaviour context”
early: JBehave, RBehave (then “was merged” to RSpec)
late: Cucumber, etc.

…creating tools to help "to be in behaviour context"
Ruby + RSpec example
describe 'Diaspora stream' do 
 
it 'should share post' do 
... 
end 
end

focus on business value...
"What’s the next most important thing the system doesn’t do?" (c)
 
it 'should share post' do 
... 
end 
 
it 'should delete post' do 
# to be implemented 
end
 
end

share all this stuff with BA, testers... that's actually same thing - speciﬁcations
 
it 'should share post'
it 'should edit post'
it 'should hide post' 
it 'should delete post'
...
 
end

(being inspired by domain-driven design ideas)
deﬁne "ubiquitous language" for the "analysis" itself
As a [X] I want [Y] so that [Z]
Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

(being inspired by domain-driven design ideas)
define "ubiquitous language" for the "analysis" itself
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.

Acceptance criteria should be executable (c)
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

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

Finally he invented…
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-deﬁned outputs, resulting in the delivery of working, tested software that
matters." (c)

Remember? outside-in BDD
TDD
tests ﬁrst
written by devs
with tests
as documentation
as behaviours
focused on business
as speciﬁcation
any mention about

TDD
tests ﬁrst
written by devs
with tests
as documentation
as behaviours
focused on business
as speciﬁcation
any mention about
notice emphasising BA terminology?

TDD
tests ﬁrst
written by devs
with tests
as documentation
as behaviours
focused on business
as speciﬁcation
any mention about
notice emphasising BA terminology?
moreover, BDD is NOT about Testing!

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)

BDD...
is about "investigation conducted by stakeholders to ﬁgure out what the product
SHOULD be" (c)
Liz Keogh’s “Showcasing the language of BDD”, May 2012

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)

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.

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 ?

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

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); 
}
...

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); 
} 
}

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") 
} 
}

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

JUnit + Fluent PageObject + Allure @steps + Gherkined One Entry Point
public class DiasporaStreamTest extends GherkinTest { 
 
@Test 
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"); 
} 
}

JUnit + Fluent PageObject + Allure @steps + Gherkined One Entry Point
public class DiasporaStreamTest extends GherkinTest { 
 
@Test 
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

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

Summary
WHEN
xUnit + static Java
AND Gherkin style of One Entry Point (aka Application Manager)
THEN
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 ﬂuently the one entry point

Summary
WHEN
Spock + dynamic Groovy
AND One Entry Point (aka Application Manager)
THEN

Summary
WHEN
Spock + dynamic Groovy
AND One Entry Point (aka Application Manager)
THEN
for some newcomers – too dynamic => prone to hardly debuggable errors
but less "ﬂuent"
less parallel tests support
test names as strings with spaces
out of the box gherkin

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

Plan?
Preface: BDD?
BDD History
Summary
Q&A
now
past
Tools retrospective
Future?

Plan?
Preface: BDD?
BDD History
Summary
Q&A
now
past
Tools retrospective
Future?
with improved UX

Plan?
Preface: BDD?
BDD History
Summary
Q&A
now
past
Tools retrospective
Future?
X tool

Afterwords
There are good practices in context,
but there are no best practices.
(c) Cem Kaner, James Bach

Thank you!
github.com/automician
automician.com
seleniumcourses.com
yashaka @
@yashaka

You are welcome;)
Selene in Python
NSelene in C#
Selenide snippets in Java
Yashaka talks src code
Selenide User Guide
@yashaka

We are looking for talents
automician@gmail.com

Iakiv Kramarenko - Don't be fooled with BDD, automation engineer

More Related Content

Similar to Iakiv Kramarenko - Don't be fooled with BDD, automation engineer (20)

More from Ievgenii Katsan (20)

Recently uploaded (20)

Iakiv Kramarenko - Don't be fooled with BDD, automation engineer