# Behaviour-Driven Development (BDD) with behave ###### tags: `Automated Testing` `Software Testing` `Test Framework` --- ## Reference - [Behaviour-Driven Development with Cucumber](https://play.google.com/store/books/details?id=TLaZDwAAQBAJ) - [Cumcumber official website](https://cucumber.io/) - [behave official website](https://behave.readthedocs.io/) --- ## Outline - BDD - One principle - Two goals - Three practice - Example mapping - Gherkin - Syntax - Demo - behave - Demo --- ## What is BDD? - A way of development focuses on closing the gap between *developers, QA and non-technical or business participants* in a software project ***to build valuable, working software***. ---- An example of where gaps might happen ```graphviz digraph where_gaps_happen{ node [ shape=box, fixedsize = true, width = 3 ]; "Manual Test Cases", "Manual Test Cases Report" [ group = 1 ]; "Automated Test Cases", "Automated Test Cases Report" [ group = 2 ]; "Software Requirement Specification", "Bug Report" [width=6.75]; "Software Requirement Specification" -> { "Automated Test Cases" "Manual Test Cases" }[color=red] subgraph cluster_2{ "Manual Test Cases" -> "Manual Test Cases Report"; } subgraph cluster_3{ "Automated Test Cases" -> "Automated Test Cases Report"; } { "Manual Test Cases Report" "Automated Test Cases Report" } -> "Bug Report"[color=red]; } ``` --- ### ONE Principle - Examples of system's behavior ---- #### 1. Examples of system's behavior - Focusing collaborative work around ***concrete, real-world examples that illustrate how we want the system to behave***. --- ### TWO Goals 1. Build shared understanding 2. Increase feedback ---- #### 1. Build shared understanding - **Using examples** to describe the behavior of the app/system/unit. - Involving stakeholders in the implementation process through outside–in software development. ---- #### 2. Increase feedback - Automating the examples - Small iterations --- ### THREE Practices 1. Discovery 2. Formulation 3. Automation ---- > The hardest single part of building a software system is deciding precisely what to build. > [name=Fred Brooks, The Mythical Man-Month] ---- #### 1. Discovery - To set the goals of ***valuable, working software***. - Technical and business people collaborate to explore, discover and **agree as much as they can about the desired behaviour for a user story**. ---- #### 2. Formulation - To **confirm** that we really do have a **shared understanding** of what to build. - Formulate each ***example*** as structured documentation. ---- #### 3. Automation - To **increase feedback** and free manual testers up to do more valuable work, like exploratory testing. - Automate ***examples*** to help us to keep our development under control. --- ## Example Mapping [^2] [^3] ----  ---- - <span style="color:blue;">Rules</span> that summarise a bunch of <span style="color:green;">examples</span>, or express other agreed constraints about the scope of the <span style="color:gold;">story</span>. - <span style="color:red;">Questions</span> about scenarios where nobody in the conversations knows what the right outcome is. Or <span style="color:red;">assumptions</span> we're making in order to progress. - new user <span style="color:gold;">stories</span> we discovered or sliced and deferred out of scope. --- ### Stories, Rules and Examples #### [@mattwynne | BDDX 2014 London](https://speakerdeck.com/mattwynne/rules-vs-examples-bddx-london-2014) ---- #### Rules vs Examples ##### AKA, The Passwords Game ---- ```graphviz graph { node [ fixedsize = true; width = 5; height =5; shape = box; color = gold1; style = filled; fontsize = 24; ] "As a administrator, I want to\n\n set a password policy and\n\n force users to create passwords\n\n accordingly so that\n\n we can contol our security level." } ``` ---- #### Create 3 rules - In your team, invent 3 rules for what makes a - valid password - Keep the rules secret from the other teams - Be imaginative, and have a bit of fun - Examples: "It must have an @ in it" "It must not be the name of a fruit" ---- #### Create 3 examples - Create 3 examples that illustrate your rules. - Scribble each one on a post-it note - Examples: ```graphviz graph { node [ fixedsize = true; width = 2; height =2; shape = box; color = darkolivegreen2; style = filled; fontsize = 24; ] "\"@pple\" \n=> valid" "\"apple\"\n=> invalid" "\"tom@to\"\n=> valid" } ``` ---- #### Sum up Describe each of these in your own words ```graphviz digraph { rankdir = LR; node [ shape = box; fixedsize = true; width = 3; height = 3; style = filled; color = cadetblue1; fontsize = 24; ] "User Story" -> "Rules/Acceptance\n Criteria" -> "Examples" "Examples" -> "Rules/Acceptance\n Criteria" -> "User Story" } ``` --- ## Gherkin ---- ### What is Gherkin? - A set of grammar rules that makes plain text structured enough to understand. - Files written in Gherkin, called *Feature files*, serve two purposes – documentation and automated tests. ---- ### Syntax ```gherkin Feature: Provide a high-level description of a software feature Scenario: A concrete example that illustrates a business rule Given put the system in a known state When describe the key action Then observe outcomes ``` ---- ### Declarative style ```gherkin Feature: Subscribers see different sets of stock images based on their subscription level Scenario: Free subscribers see only the free articles Given Free Frieda has a free subscription When Free Frieda logs in with her valid credentials Then she sees a Free article on the home page Scenario: Subscriber with a paid subscription can access both free and paid articles Given Paid Patty has a basic-level paid subscription When Paid Patty logs in with her valid credentials Then she sees a Free article and a Paid article on the home page ``` ---- ### Imperative style ```gherkin Feature: Subscribers see different sets of stock images based on their subscription level Scenario: Free subscribers see only the free articles Given users with a free subscription can access "FreeArticle1" but not "PaidArticle1" When I type "freeFrieda@example.com" in the email field And I type "validPassword123" in the password field And I press the "Submit" button Then I see "FreeArticle1" on the home page And I do not see "PaidArticle1" on the home page Scenario: Subscriber with a paid subscription can access "FreeArticle1" and "PaidArticle1" Given I am on the login page When I type "paidPattya@example.com" in the email field And I type "validPassword123" in the password field And I press the "Submit" button Then I see "FreeArticle1" and "PaidArticle1" on the home page ``` ---- ### Writing better Gherkin[^1] - Your scenarios should describe the intended (what) behaviour of the system not the (how) implementation. - A more declarative style hides the details of how the application’s capabilities are implemented. --- ## Behave ---- ### Installation ```bash pip install behave ```  ---- ### Execution ```bash= behave --format=cucumber_json:PrettyCucumberJSONFormatter -o data.json ``` ---- ### Integrated with Jira and Jenkins - [Jira](https://moxa-trd.atlassian.net/browse/TAU5G-348) - [Jenkins](http://10.144.45.104/jenkins/view/RouterPlatform/job/Build_5GTAU_Test/)  [^1]: [Writing better Gherkin](https://cucumber.io/docs/bdd/better-gherkin/) [^2]: [Introducing Example Mapping](https://cucumber.io/blog/bdd/example-mapping-introduction/) [^3]: [Your first Example Mapping session](https://cucumber.io/blog/bdd/your-first-example-mapping-session/) [^4]: [Myths about BDD](https://cucumber.io/docs/bdd/myths/) [^5]: [Behaviour-Driven Development](https://cucumber.io/docs/bdd/)