![Acceptance Criteria/Scenarios
• Scenarios are described in Given [initial
context] When [event occurs] Then [ensures
some outcome] notation](https://image.slidesharecdn.com/cucumber-jvmbestpracticesv3-200315143553/75/Cucumber-jvm-best-practices-v3-16-2048.jpg)
Uploaded byAhmed Misbah
Cucumber jvm best practices v3
This document provides an overview of Cucumber-JVM best practices for behavior driven development. It discusses layers of agile development including test driven development and behavior driven development. It then explains Cucumber-JVM and Gherkin syntax for defining features, scenarios, steps, and tags. Finally, it outlines best practices for writing feature files, using code coverage, and building test data in step definitions.
More Related Content
Similar to Cucumber jvm best practices v3
Cucumber jvm best practices v3
- 1.
- 2. Agenda • Introduction – Layersof Agile Development – Test Driven Development – Behavior Driven Development • Cucumber-JVM • Best Practices
- 3. Rules • Phones silent •No laptops • Questions/Discussions at anytime welcome • 10 minute break every 1 hour
- 4.
- 5. Layers of AgileDevelopment
- 6. Agile Practices • PairProgramming • Test Driven Development • Acceptance Test Driven Development • Behavior Driven Development • Specification by Example • Collective Ownership • Continuous Deployment • Continuous Integration • Version Control • Definition of Ready • Definition of Done
- 7. Test Driven Development •Test-Driven Development (TDD) is a software development process that relies on the repetition of a very short development cycle • Requirements are turned into very specific test cases, then the software is improved to pass the new tests only • Kent Beck is credited with having developed or 'rediscovered’ the technique
- 8. TDD and XP •Testing in XP: – All code must have unit tests – All code must pass all unit tests before it can be released. – When a bug is found tests are created before the bug is addressed (a bug is not an error in logic, it is a test that was not written) – Acceptance tests are run often and the results are published
- 10. How do wedo TDD?
- 11. Behavior Driven Development(1/2) • Behavior-Driven Development (BDD) is a software development process that emerged from Test-Driven development (TDD) • It combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development
- 12. Behavior Driven Development(2/2) • BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes • DSL can be written as Test Scripts and converted into Fixtures for automating tests
- 13. Behavioral Specifications • Title:The story should have a clear, explicit title: Narrative A short, introductory section that specifies: – who (which business or project role) is the driver or primary stakeholder of the story (the actor who derives business benefit from the story) – what effect the stakeholder wants the story to have – what business value the stakeholder will derive from this effect • Acceptance criteria or scenarios: a description of each specific case of the narrative. Such a scenario has the following structure: – It starts by specifying the initial condition that is assumed to be true at the beginning of the scenario. This may consist of a single clause, or several – It then states which event triggers the start of the scenario – Finally, it states the expected outcome, in one or more clauses
- 14. User Stories • Writtenin the following notation: – As who – I want what – So that why • A User Story has three components (3Cs): o Card o Conversation o Confirmation
- 15. An example ofa User Story
- 16. Acceptance Criteria/Scenarios • Scenariosare described in Given [initial context] When [event occurs] Then [ensures some outcome] notation
- 18. Problem Domain vs.Solution Domain Problem Domain Solution Domain Implement Validate
- 19. BDD Frameworks andLibraries • Cucumber (Java and Ruby) • JBehave (Java) • Behat (PHP) • Jasmine (JS)
- 20.
- 21. Cucumber • Cucumber isa software tool that computer programmers use for testing other software • It runs automated acceptance tests written in a behavior-driven development (BDD) style • Gherkin is the language that Cucumber uses to define test cases
- 22. Gherkin • Gherkin isdesigned to be non-technical and human readable, and collectively describes use cases relating to a software system • It seeks to enforce firm, unambiguous requirements starting in the initial phases of requirements definition by business management and in other stages of the development lifecycle • In addition to providing a script for automated testing, Gherkin's natural language syntax is designed to provide simple documentation of the code under test
- 23. Cucumber/Gherkin Syntax • AllGherkin files have the .feature file extension. They contain a single Feature definition for the system under test and are an executable test script • Cucumber tests are divided into individual Features. These Features are subdivided into Scenarios, which are sequences of Steps
- 24.
- 25.
- 26.
- 27. Steps (1/2) • Given- Describes the preconditions and initial state before the start of a test and allows for any pre-test setup that may occur • When - Describes actions taken by a user during a test • Then - Describes the outcome resulting from actions taken in the When clause • And - Logical and • But - Logically the same as And, but used in the negative form
- 28.
- 29. Tags (1/2) • Gherkin'sFeature structure forces organization. However, in cases where this default organization is inconvenient or insufficient, Gherkin provides Tags • Tags are @-prefixed strings and can be placed before: – Feature – Scenario – Scenario Outline – Examples
- 30.
- 31. Cucumber-JVM • Cucumber-JVM isa pure Java implementation of Cucumber • Cucumber-JVM also integrates with all the popular Dependency Injection containers (e.g. Spring)
- 32.
- 33. Hooks • Hooks areCucumber's way of allowing for setup to be performed prior to tests being run and teardown to be run afterwards • Three basic types of hooks exist: – Before - Runs before a scenario – After - Runs after a scenario – Around - Assumes control and runs around a scenario • Additional hooks include: – BeforeStep – AfterStep – AfterConfiguration - Runs after Cucumber configuration and is passed an instance of the configuration
- 34.
- 35. Feature file writing •Feature files should be written using one of the following approaches: – Specification workshops - when starting out, having the whole team attend specification workshops acts as a useful introduction to the approach. Over time, some teams decide to continue with a whole-team approach, while others reduce the number of people in each session. – 3 Amigos - suggests a minimum of 3 functional roles; developer(s), tester(s) and business analyst or product owner. – Example mapping - uses index cards as a means to engage all team members collaboratively and visually map the story, acceptance criteria or rules, and examples.
- 36. Code Coverage • CodeCoverage should not rely entirely on Feature Files • Feature files should cover Acceptance Tests • Most code coverage should come from Unit Tests
- 37. Feature Files WritingGuidelines 1. All scenarios must be independent and deterministic. This means that the scenario should run alone successfully without depending on other feature files or scenarios to run before it 2. Use DRY concept in writing Cucumber/Gherkin feature files. This means that step definitions should be written in a form that will make them reusable and easy to refactor 3. Use Scenario Outlines. This implies writing single scenarios for testing multiple data and relying on examples to describe test data and verify different outcomes
- 38. Feature Files WritingGuidelines (cont’d) 4. Use regular expressions in Step Definitions for ignoring plurals to promote reusability particularly in setting up test data Given the following user exists | Username | Role | | msaeed | Budget_Manager | Given the following users exist | Username | Role | | msaeed | Budget_Manager | | msaeed | Budget_Manager | @Given("^the following users? exists?$") public void the_following_user_exists(List<UserTestCommand> userList) throws Throwable{ }
- 39. Feature Files WritingGuidelines (cont’d) 5. Use tables in feature files for writing “When” steps Bad Practice
- 40. Feature Files WritingGuidelines (cont’d) Good Practice
- 41. Feature Files WritingGuidelines (cont’d) 6. Setting up test data will be using: – Tags (SQL scripts for global data - Separate tag for each entity - Tag for all data - Use flyway migration scripts) – Background (for feature specific data) – Given (for scenario specific data) 7. Truncate all tables from one scenario to the other and run SQL migrations
- 42. Feature Files WritingGuidelines (cont’d) 8. One step definition per API command for setting up test data 9. Use business identifiers in feature file test data
- 43. Building Test Datain Step Definitions • Test data defined in Cucumber/Gherkin feature files should be persisted using Builders that will call the actual production APIs. The Builders will construct the API Commands that will be used to call the REST APIs
- 44. Building Test Datain Step Definitions • Cucumber only injects objects that are declared in the Step Definition class currently being run. To overcome this problem, Cucumber glues are declared in Spring Context XML to allow the glue class to be injected in all classes that run • Injecting all builders into a single class (or factory) and declare this class as Cucumber Glue. Any class that will use a builder will retrieve the builder from the Builder Factory
- 45.