kaleidoscope

In our previous post  Behavior Driven Development  we discussed BDD. Here, let's look at  Cucumber.  The flagship BDD framework for java, but not limited to Java. Why Cucumber As we saw in the previous post, until the Automation phase, BDD is all about discovering and formulating  behavioral scenarios  through collaboration. Its the automation phase, where things really happen. It would be easy if we could write these behavioral scenarios in plain English ( or another preferred spoken language ) and runtime could understand and execute those for us. This is where Cucumber comes to the rescue. Cucumber Cucumber is a framework that let us write application-behavioral-expectations in meaningful spoken-language-text using  Gherkin. Cucumber implementations are available in many programming languages as shown below. Courtesy — Cucumber.io supported programming languages NOTE: It's recommended (not mandatory) to choose an implementation for the same platform...

In  previous post  we had an overview of the Cucumber, Gherkin & feature file. Now let's see how to write test cases in feature files using Gherkin. Anatomy of a feature-file All non-blank lines in a  feature file  have to start with a valid  Gherkin keyword.  Some of them we discussed in the previous post. Here is the description of the main Gherkin keywords. Feature: The first Keyword in feature-file must be  Feature,  it must be followed by   : After  Feature:  cucumber ignores all the text and lines for processing until a line starting with either  Scenario ,  Background,  or  Scenario Outline  keyword is found. All the text in between is used only for reporting purposes.  The first line is used as the feature name, and the remaining lines (if present) are used as feature descriptions. Scenario: Scenario keyword must also be followed by  :  .  Any text after  :  in this ...

A wise man ( narcissist me ) once said, “Life is all about the question and answers. The trick to a meaningful life is,  To ask the right questions to yourself, so you can get on the right path to search for the answer .” The very first question one should always ask oneself is WHY.  Let's discuss our WHY in the current case. Why BDD Let's take a step back and start with the well-known software development practice TDD ( Test-Driven Development).  In TDD, the very first thing developers do is, set up the technical expectations from the code by writing failing test cases. After the expectation is set, the code is written/modified to finally pass all of the failing tests. It's an  Acceptance driven development strategy . TDD works fine to create a robust technically working product. But the whole TDD approach revolves only around technical teams. It barely involves the business analysis or product owners to validate the business aspect of a feature, they get involved o...