PR Link: https://github.com/cucumber/docs.cucumber.io/pull/429
Duration: 60 mins
My second session with Lisa Crispin turned out to be a strong style pairing session as each of us assumed the driver/navigator role. Lisa was already working on adding better documentation on explaining declarative vs imperative style of Gherkin. Am a complete noob with regard to Cucumber/Gherkin and Lisa was briefly explained the what/how behind it. Her PR was already in progress and she needed help navigating via IntelliJ and git commands which I was familiar with.
Based on my understanding: Cucumber is a testing tool that supports behavior driven development. BDD is a way for software teams to close the gap between business and technical people. It defines application behavior using simple English text defined by a language called Gherkin.
Cucumber was initially implemented in Ruby and then extended to Java framework and it supports JUnit as well. All the stakeholders: developers, product managers, QEs, project managers, etc. brainstorm as to which test scenarios are required to ensure that the application is successful. All these test scripts are in simple English as it serves as good documentation as well.
Let’s take an example of user authentication, the following can be valid test scenarios:
- The user should be able to login with valid username and password.
- The user should not be able to login with invalid username and password.
- The user should not be able to login with valid username and invalid password.
The above test scenario uses declarative style of communication. Lisa explained that this is easier to maintain and less brittle. It only describes the behavior of the application rather than the implementation details.
Whereas an example of imperative style applied for the same example would look like this:
- The username is testuser@gmail.com and password: test123 should be allowed to login.
- Username: testuserxxx@gmail.com and password: 123456 is invalid.
- Username: testuser@gmail.com and password: 123456 is invalid.
The above example requires maintenance as the values are subject to change anytime. Hence it is brittle.
Lisa, in her PR was giving a similar example and explaining the 2 different styles of gherkin documentation. Soon her PR was ready to be committed, pushed to the remote branch and ready for review.
Thank you Lisa for pairing with me! Had an awesome learning session! Hugs! :)
