BDD (Behavior-driven development), also known as ATDD (Acceptance test–driven development) is a software development process that helps Agile teams design, develop, test and deliver software efficiently, it's about how to implement agile acceptance testing and binding business requirements to code. BDD helps to bridge the communication gap between stakeholders and implementation teams, build quality into software from the start, design, develop and deliver systems fit for purpose. SpecFlow is the official tool to implement BDD on the .NET platform.

1. Behavior Driven Development
with SpecFlow and Selenium
Liraz Shay
liraz.shay@yahoo.com

2. About me
● Test automation expert
● Extensive experience in BDD and SpecFlow
● QA and Automation leader at BurlingtonEnglish
● Blogger (SeleniumPro.net)

3. Goals
Learn about BDD and Specification-By-Example
Learn all (almost...) about SpecFlow
New perspective for SpecFlow users
BDD / Cucumber best practices

4. Terminology
❖ Specification-By-Example
❖ Acceptance Test Driven Development (ATDD)
❖ Behaviour Driven Development (BDD)

5. Presentation Topics
❏ Quick intro/refresh on Specification-By-Example
❏ Introduction to Gherkin
❏ SpecFlow main features
❏ Code examples
❏ SpecFlow and BDD best practices
❏ Short brief about our Selenium-based automation framework
❏ Time for questions

6. Specification-By-Example
A single source of truth of
software behaviour.
For both non-technical and
technical project members.

7. The people in charge of defining the requirements (business
analysts) sit down with programmers and testers and discuss a
feature to be implemented. (These roles are often called the three
amigos).
The three amigos come up with examples of how the software
should behave,
At the end, they write them down as Cucumber Scenarios.
Specification Workshops (Three Amigos)

11. Feature vs Scenario

13. Outside-In Development (Programmers)
Programmers run those Cucumber Scenarios with
Cucumber, which tells them what needs to be implemented -
what’s missing.
They code a little bit, run Cucumber again and continue until
the feature works as described.

14. BDD Cycle

15. Gherkin
.feature files
Gherkin is plain-text English with a
little extra structure.
Gherkin is designed to be easy to
learn by non-programmers
But structured enough to allow
concise description of examples to
illustrate business rules in most
real-world domains
➢ Feature
➢ Scenario
➢ Given, When, Then, And, But (Steps)
➢ Background
➢ Scenario Outline
➢ Examples.

16. Given
Given steps are used to describe the initial context of
the system ---the scene of the scenario.
It is typically something that happened in the past.
It's ok to have several Given steps (just use And or
But)

17. When
When steps are used to describe an event, or an
action.
This can be a person interacting with the system, or
it can be an event triggered by another system.
It's strongly recommended you only have a single
When step per scenario.

18. Background
Instead of repeating the same Given steps in all of the scenarios,
You can literally move such Given steps to the background by
grouping them under a Background section before the first
scenario:

19. Scenario Outline
When you have a complex business rule with several
variable inputs or outputs you might end up creating
several scenarios that only differ by their values.

20. Instead of:

21. Much easier to read...

22. Show me the code !!!!!

23. Purpose of examples
❖ Shared understanding of the acceptance criteria
❖ Documentation: system details
❖ Regression-tests

24. Test automation becomes expensive, when..
❖ Trying to automate manual tests
❖ Making tests unreadable when automating them
❖ Automating only after completing implementation

25. Best Practices

26. Write declarative features
Scenarios should be written like a user would
describe them (as specification, not as test script.)
Beware of scenarios that only describe clicking links
and filling in form fields, or of steps that contain code
or CSS selectors.

27. Specifications, not scripts:
less workflow based
scenarios
more specifications about
what is needed,
as these are easier to
understand, more precise
and testable;

28. Abstract:
the specification
should be abstract
enough to highlight
the detail,
remove the noise,
and not being tied to
the implementation of
the user interface;

29. Push HOW down see:
http://www.marcusoft.net/2013/04/PushTheHowDown.html
When all you really
wanted to say was:

30. Push HOW down see:
http://www.marcusoft.net/2013/04/PushTheHowDown.html
it's pretty easy to
automate with a few
generic step
definitions

31. Push HOW down see:
http://www.marcusoft.net/2013/04/PushTheHowDown.html
The first version sucks because:
● it's almost impossible to see the
"tree for the forest". What is
this scenario describing?
● It's boring for any non-technical
person to read
● It was meant to clarify but it just
added confusion

32. Push HOW down see:
http://www.marcusoft.net/2013/04/PushTheHowDown.html
The second version is better
because:
● it clearly shows the (in this case
very simple) behavior.
● It's understandable by everyone,
even non-techies, even techies.
where did the HOW go then?

33. Push HOW down see:
http://www.marcusoft.net/2013/04/PushTheHowDown.html
Should we keep the HOW here ?
Well - no... keep pushing
Try to keep your step definition
as simple as possible, preferable
one-liners.
These one-liners can interact
with a DSL or Driver object that
you use to interact with your
system. (Page Objects)

34. Use page-objects
Page objects are just a design
pattern to ensure automated UI
tests use reusable, modular code.
Not using them, eg, writing
WebDriver code directly in step
definitions, means any changes to
your UI will require updates in
lots of different places instead of
the one ‘page’ class.

35. Think twice when writing the "As a ... I want to .. so I can ..."
Parts of a user story (Specification by Example, page 72)
• As a stakeholder
• In order to achieve something valuable
• I want some system function
For example,
“As a marketing manager,
so that I can market products directly to customers,
I want the system to request and record personal information when customers register
for a loyalty program.”

36. Stop once you've an expectation
● No more user actions (click_link and friends) after a Then
● Only assert on Then steps
● Split complicated workflows in different scenarios (i.e.
registration + confirmation + profile completion)

37. Anti Patterns
Scenario Outlines
Step params (Given a user named "John Doe")
Tables

38. Bad name on a scenario
A good name on a scenario tell the reader what this
is about. No name leaves the reader guessing.
Scenario: Sign up, login, go to balance screen, check balance, logout
Scenario: Check balance

39. Lots of user interface details
One problem with this is understanding the purpose.
Another problem is that user interfaces changes a lot
more frequently than the underlying domain logic.

40. No clear separation between Given/When/Then
What is the difference then?
Given is the context - the past
When is an action that changes the system - the
present
Then is the expected outcome - the near future

41. SpecFlow Report see:
https://github.com/techtalk/SpecFlow/wiki/Reporting

42. ReportUnit see: http://relevantcodes.com/reportunit/

43. Pickles Living Documentation see: http://www.picklesdoc.com

44. Selenium Framework
Driver.AreYouOn<LoginPage>() : bool
Under the hood:
Create new instance of the login page with short timeout,
If exception was thrown - return false, else true

45. Selenium Framework
Driver.GoTo<LoginPage>() : LoginPage
Under the hood:
Take the url of the page from the attribute, and navigate to that
page, then return new instance of the login page

46. Selenium Framework
Page Verifier Attribute
Under the hood:
When creating a new instance of login page, The constructor of
the base class finds the elements with PageVerifierAttribute and
verifies / wait until they are displayed

47. Selenium Framework
PageComponent vs PageObject

48. Selenium Framework
Html Elements
Implement classes for common
elements with relevant methods,
TextField - ClearAndType(text)
DropDownList - Select(value/text)
RadioButton -
Check/Uncheck/IsChecked,
etc.

49. Selenium Framework
WebDriver Wrapper + WebElement Wrapper
Architecture to achieve 100% Stable tests, no unwanted exceptions
For each method on IWebElement:
1) If element is StaleElementReference - Find it again
2) If any exception was thrown while executing the method (click(),Text,etc.) - try again
until 20 sec - if this didn't help - throw the exception
Open source implementation will be available soon in my GitHub
Project name StableSelenium

50. Other platforms
Cucumber supports over a dozen different software platforms: See: https://cucumber.io/docs

51. Books

52. Useful links
http://www.specflow.org/resources/
https://www.youtube.com/playlist?list=PL6tu16kXT9Pp3wrsaYyNRnK1QkvVv6qdI
http://www.testingexcellence.com/bdd-guidelines-best-practices/
http://www.thinkcode.se/blog/2016/06/22/cucumber-antipatterns

53. Any questions ?