Behavior Driven Development by Example
Download as PPT, PDF7 likes4,297 views
A practical approach BDD using Cucumber-jvm and web driver with introduction to process and technology integration. Colombo Selenium meetup group.
![The framework anatomy
Page Object layer (Pages and Elements)
get_element1
Page One
Page Two
Page Three
get_element
2
Basic Action Layer
Composite action Layer (Helper abstract layer
-Business flow layer)
[Transferring browser
control over page objects]
action_element1
action_element2
Starting comp action
Intermediate Comp Action
Exiting comp Action
Step Definition Layer (Collection of methods annotated in
Cucumber/Gherkin - Given, When, Then, But or And)
Junit executor class
Feature Layer (Actual test cases represented as scenarios written in
annotated names in step definition class.)](https://image.slidesharecdn.com/bddv2-140220115248-phpapp01/85/Behavior-Driven-Development-by-Example-16-320.jpg)
![The transition
In the original proposal the transition would be just using ―should‖ instead
of ―test‖ in the unit testing!
User story: "As a [role] I want [feature] so that [benefit]".
Scenario: ―Given [initial context], when [event occurs], then [ensure some
outcomes]‖
Test method names should be sentences
A simple sentence template keeps test methods focused
An expressive test name is helpful when a test fails
―Behavior‖ is a more useful word than ―test‖
Requirements are behavior,too
Acceptance criteria should be executable](https://image.slidesharecdn.com/bddv2-140220115248-phpapp01/85/Behavior-Driven-Development-by-Example-37-320.jpg)
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to Behavior Driven Development by Example (20)
Ad
Recently uploaded (20)
Behavior Driven Development by Example
- 1. BDD – By Examples Behavior Driven Development with Selenium/ Cucumber-JVM Nalin Goonawardana
- 2. The audience Automated acceptance testing? Agile/Scrum? CI? BDD?
- 3. BDD/BDT – Connecting the dots Agile Cucumber User Stories UATDD Features Gherkin Scenarios BDD-2003 Step Definitions TDD Steps Dan North Thought Works Jason Huggins JBehave CucumberJVM Specification by Example Selenium2004
- 4. DSL Business language --- DSL Specification by Example On the other hand a good functional test tells a story!
- 5. The concept of ―Xdriven‖ You are driven by something to do something or achieve something. i.e. What do you set as the guiding line that governs how you establish some other task! Few examples: Capability driven development Model driven development Test driven development Passion driven development Requirement driven development? What drives us to do something or what you do first! Of course it is not ―Bug driven development where the developer only get to know the expected requirement through a bug!
- 6. How close we are - Requirements User The creation of functional tests and "features" User Interface Expected behavior User acceptance Testing Functional Testing Integration testing Service layer testing Module Module level testing/Unit te Class Unit?-method? The creation of unit tests and "technical" code Unit testing Developer
- 7. What is wrong with Unit tests Developer testing Vs. Behavior compliance. Requirement Or Expected behavior BA/QA/User Explicit collaboration effort that May vary Developer Verification and validation at unit test level
- 8. Gaps and Cracks Bugs One common set of verifications that collaboratively making passed as the exit criteria or done-ness criteria
- 9. Gaps and Cracks Contd.. The gap between unit tests : high-level software requirements, low-level technical details Behavior Requirement
- 10. Executable Specification - User stories Executable specifications Apply the "Five Why's" principle to each proposed User Story, so that its purpose is clearly related to business outcomes Thinking "from the outside in", in other words implement only those behaviors which contribute most directly to these business outcomes, so as to minimize waste Describe behaviors in a single notation which is directly accessible to domain experts, testers and developers, so as to improve communication Apply these techniques all the way down to the lowest levels of abstraction of the software, paying particular attention to the distribution of behavior, so that evolution remains cheap
- 11. What makes BDD different? It technically Integrates the requirement to the SDLC. It demands developer to align the development with user requirement from the beginning. It is a engineering work bench that support requirement driven deveolopment.
- 12. BDD and BDT
- 13. How do we implement this? Process or workflow alignment Technical solution
- 14. The work-flow Feature > Scenarios Feature/Behavior Test Fixtures App implementation Acceptance
- 15. BDD phases Elicitation – BA/Customer (Product) Elaboration – BA/QA (Product/QA) Implementation of feature - Dev Implementation of steps - QA Validation(Exploratory+BDT) Acceptance(Product owner-Demo)
- 16. The framework anatomy Page Object layer (Pages and Elements) get_element1 Page One Page Two Page Three get_element 2 Basic Action Layer Composite action Layer (Helper abstract layer -Business flow layer) [Transferring browser control over page objects] action_element1 action_element2 Starting comp action Intermediate Comp Action Exiting comp Action Step Definition Layer (Collection of methods annotated in Cucumber/Gherkin - Given, When, Then, But or And) Junit executor class Feature Layer (Actual test cases represented as scenarios written in annotated names in step definition class.)
- 17. The framework anatomy contd.. Page Object layer (Pages and Elements) Basic Action Layer Composite action Layer (Helper abstract layer -Business flow layer) Step Definition Layer (Collection of methods annotated in Cucumber/Gherkin - Given, When, Then, But or And) Feature Layer (Actual test cases represented as scenarios written in annotated names in step definition class.)
- 18. TDD process and it’s roots Specify Behaviour Write little test Refactor Implement the App complying to the Behaviour Watch test fail Get test pass Wire steps with automation code
- 20. The jargon Feature : Piece of system functionality that delivers value. User story : Vertical functional slice of a feature that can be delivered independently Scenario : One key example for a feature in the feature file. This amounts to the main functional flows/ behaviors * critical data (derived through a test design technique) Step: Domain language phrases which can be combined to create scenarios.
- 21. Cucumber Cucumber is a testing framework that speaks the language of Gherkin. It wires the .feature or the executable spec to its corresponding test implementation the ―step definitions‖. Using Cucumber doesnt mean you are practicing BDD!
- 22. Cucumber-JVM and the tech stack • Cucumber-JVM is a pure Java implementation of Cucumber, with native support for the most popular JVM languages: Java, Scala, Groovy, Clojure, Rhino, Jython and JRuby. • Selenium Web Driver : Java : Junit : Maven
- 23. Gherkin in two mins Gherkin is the language that Cucumber understands. purposes — documentation and automated tests it’s talking to you, telling you what code you should write. Single Gherkin source file contains a description of a single feature. Source files have .feature extension.
- 24. Gherkin in two mins ….. Features,User Stories, Scenarios and steps line-oriented language that uses indentation to define structure Line endings terminate statements Either spaces or tabs may be used for indentation lines start with a keyword (Feature,Background,Scenario,Scenario Template,Given,When,Then,And,But) Comment lines are allowed anywhere # Regular expressions Tables
- 25. Gherkin in two mins ….. Keywords Given : Pre condition When: primary action of a scenario Then : Post condition, expected observable outcomes. And, But If you have several Given, When or Then steps.
- 26. Data driven Scenario Outline: Login Success and Failure Given I navigate to the mock application When I try to login with '<type>' credentials Then I should see that I logged in '<status>' Examples: | type | valid | invalid | status | | successfully | | unsuccessfully|
- 27. Setting up the IDE Pre conditions: IntelliJ IDEA 12 Community Edition In the IDE add the following plugins; Settings> IDE settings > Plugins > Install JetBrains Plugins > Gherkin V1.1 Settings> IDE settings > Plugins > Install JetBrains Plugins > Cucumber for Groovy V1.0 Settings> IDE settings > Plugins > Install JetBrains Plugins > Cucumber for Java V1.0
- 28. IDE features 1. Code Completion (Step definition and Gherking syntax support) 2. Cucumber Framework Support 3. Drill down from *.feature file to step definition 4. Code Formatting 5. Junit runner support
- 29. Framework Changes Step 1 – Adding Maven Dependencies Simple five steps approach in the framework level changes Assumptions Existing Java/Junit/Maven/Web Driver based test framework. Or Create an empty maven project Apart from the junit/Selenium deps add the following deps to the maven pom file <dependency> <groupId>info.cukes</groupId> <artifactId>cucumber-java</artifactId> <version>1.1.4</version> <scope>test</scope> </dependency> <dependency> <groupId>info.cukes</groupId> <artifactId>cucumber-junit</artifactId> <version>1.1.5</version> <scope>test</scope> </dependency>
- 30. Framework Changes Step 2 - Set up package structure
- 31. Framework Changes Step 3: Add the junit runner class
- 32. Framework Changes Step 4 - Add the step definition class
- 33. Framework Changes Step 5 - Add the feature file
- 34. The role of the CI dashboard Create a view in the name of the sprint and add the junit runner class to separate new projects and let every one know where we are!
- 35. Demo Sprint X starts Scenarios were written Create CI project dashboard for Sprint X and initiate. QA : Write the test fixture and implement any step definitions. Use mock elements(xpath or id etc.) refering to the wire frames and create the page objects. Replace them with the real element references as soon the details available. Dev: Implement the Code Tests getting passed progressively Done: All tests are passed + Planned manual tests are executed.
- 36. Auto generated code skeleton @Given("^add (d+) and (d+)$") public void add_and(int arg1, int arg2) throws Throwable { // Express the Regexp above with the code you wish you had throw new PendingException(); }
- 37. The transition In the original proposal the transition would be just using ―should‖ instead of ―test‖ in the unit testing! User story: "As a [role] I want [feature] so that [benefit]". Scenario: ―Given [initial context], when [event occurs], then [ensure some outcomes]‖ Test method names should be sentences A simple sentence template keeps test methods focused An expressive test name is helpful when a test fails ―Behavior‖ is a more useful word than ―test‖ Requirements are behavior,too Acceptance criteria should be executable
- 38. Agile Scrum Alignment Feature : Backlog item Scenario: Test case Donness : Built in - Green report + Manual expert/exploratory testing sign off. Continuous collaboration : BDD enforces it. Continuous integration : BDD enforces it. (Part of the build.) Recommends automation : BDD enforces it. Just enough/living documentation that serve multiple purposes. Always know how much is remaining.
- 39. Manual testing? Expertize driven testing Exploratory testing Regression ? Limitations of automation ?
- 40. Can we only do BDT without BDD Yes and a No! BDT can be identified as the means of realizing BDD.
- 41. Some more advantages Non technical BA's Product owners, OPS, Dev, QA speaking the same language Defines Doneness criteria Automated Regression Test suites. No compilation issues only runtime. User expected behavior conformance is maintained from the beginning...
- 42. Advantages Contd… Tests can become truly useful documentation Helps you to separate "what?" from "how?" Purposely small command-set is simple to learn Separating requirements from implementation helps refactoring Specifications can be as thorough as unit tests Specifications can be hooked in at different levels Agreeing details up-front allows finer control over scope Test coverage no longer relies on developer self-discipline automatic generation of technical and end user documentation from BDD "specifications"
- 43. The collaboration • In BDD a significant portion of "functional documentation" defined in the form of ―User Stories‖. • "tests", a BDD practitioner will prefer the terms "scenario" and "specification". • "functional tests", the preferred term will be "specifications of the product's behavior". • "the unit tests of a class", a practitioner or a team using BDD prefers to speak of "the specifications of the behavior of the class"
- 44. You are already a BDD practitioner If you are practicing TDD properly BDD, often described as ―TDD done well‖ User focused TDD
- 45. TOOLS JSpec - JavaScript Behavior Driven Development SpecFlow - Pragmatic BDD for .NET • • • • • • • • FitNesse Cucumber (software) Framework for Integrated Test JBehave Robot Framework Concordion specs2 specflow
- 46. BDT is a paradigm shift for QA • Reclaiming the QA role within the Agile world • No tests but scenarios! • Technical convergence • Early/Parallel automation. • Just enough Engineering practices! • Tests frameworks without layers ! Record and play ! • Highly engaged requirement deal • Its not about the tools but about the practices !
- 47. Future implementations API Testing (In conjunction with Rest Assured) Performance testing (In conjunction with Jmeter) Consolidated online CASE tool? A communication and collaboration framework for developers, QA and nontechnical or business participants in a software project.
- 48. More • http://aslakhellesoy.com/post/20006051268/cucumber-jvm-1-0-0 • http://www.ibm.com/developerworks/opensource/library/a-automatingria/index.html • RSpec, Cucumber and GivWenZen(Fitness) • FitNess • http://fitnesse.org/ • Xebium : Combine the power of Selenium • http://xebia.github.io/Xebium/ • BDD original proposal • http://dannorth.net/introducing-bdd/
- 49. Q&A