Cucumber BDD in the Trinity (MVC)

(A Variant of Hybrid Testing Framework)

“My wife suggested I call it Cucumber (for no particular reason), so that’s how it got its name.” — Aslak Hellesøy

Aslak Hellesøy (Developer of Cucumber) was smart to observe and understand the ambiguous requirements and misunderstandings and gaps created for non-technical and technical members of a project team developed this BDD framework(and also a smart husband ,took the suggestion of wife and credited her for the Name)

Most often anybody hear the type of automation testing framework implemented in their project or company is “Hybrid Testing Framework”. Although the Hybrid Testing Framework principles can be put across the broader scope, still it is used in precipitancy or context of respective person’s coinage although their framework doesn’t meet the basic principles.

“Hybrid Testing Framework” is type of framework which unites the advantages of “DataDriven Framework” and “Keyword Driven Framework”. For the uninitiated-

“DataDrivenFramework” — a type of framework, where the test cases written inside the framework are executed using the input data/expected output taken from an external source.

“Keyword Based Framework” in turn is to write the testcases consisting of certain set of keywords in an external source and actions for these keywords and data will be inside the framework.

Cucumber BDD

Cucumber is a tool which supports behavior driven development which execute the tests written in normal English(with some Gherkin verbiages) as automated tests and any non-technical person can write these automated testcases by keeping the product eye-view also. The same template can be reused as manual test specification ,thus by avoiding the duplicity. It also augments well with keywords of Keyword driven Framework and carry forward the advantages of the Keyword driven Framework.

The File in which we write automated testcases in normal English/Gherkin is called Feature file and each step/sentence corresponds to an action which needs to be written in another file called step definition file, which can be written in JAVA, Python and Ruby etc.

A typical Cucumber BDD Testcase (combination of Gherkin keyword and normal English sentences) looks like-:

The Three Musketeers:

A Meeting called –The Three Amigos will take place where it takes the user stories and convert into clean, thorough Gherkin scenarios. It involves three voices (at least):

· The product owner — This person is most concerned with the scope of the application. This involves translating user stories into a series of features. As the tester comes up with edge cases, the product owner is responsible for deciding what is within scope.

· The tester — This person will be generating lots of Scenarios, and lots of edge cases. How will the application break? What user stories have we not accounted for within these Features?

· The developer — This person will add many of the Steps to the Scenarios, and think of the details that go into each requirement. How will this application execute? What are some of the roadblocks or requirements behind the scenes?

“If we take these concepts and put through the lens of the typical MVC testing framework- the feature files can be put under the Views i.e. (V) of MVC and the step definition files can be put under the Controller i.e. (C ) of the MVC. In most of the times, the OS specific data will be present in the Model(M) i.e platform(Web, Android and iOS) specific locators are added.”

MVC — The Trinity.

“The key to universe lies in the trinity i.e. 3, 6 and 9” — Nikola Tesla

MVC is Model View Controller framework which is typically used for technical architecture of the development of the product. The same can be imbibed to an automation testing framework where

M — Model — typically consists of DAOs (Data Access Objects) for us it is Page Objects (converting each page of the product to an object using Page Factories).

V — View — typically consists of user interface or representation of information in a particular format in an understandable way. In our case — it will be TESTCASE.

C- Controller — typically consisting of the business logic where the execution is done on the data using the DAOs. In our case it will be step definition files.

There are some additional features required for a MVC testing framework like

i. Executing the each step multiple times with various set of data.

ii. Executing the each testcase repeatedly with different set of data.

iii. Maintaining the object state for various steps/testcases.

Usually we use @DataProvider and @Factory modules of TestNG to facilitate the above features but for maintaining object state, we need to manually code it.

Cucumber BDD has taken a step forward and introduced features like DataTables/Scenario background to execute the steps/scenarios multiple times with various set of data. For maintaining the object states –it requires to use the dependency injections.

A note on Dependency Injectors

Typically when cucumber executes a step — it constructs the object each time newly and previous helper data may not be available for next executions. There are tools available which are bundled along with the cucumber like the Pico and Guice which helps in maintaining the state of object between the test executions to make the code simpler.

Conclusion:

Cucumber BDD offers even to the non -technical persons to write and automate the functional/flow test cases as it is easily pluggable to the MVC based Testing frameworks

What next?

Serenity is another tool in offering which is an improvement on Cucumber BDD which is getting updated and taking a notch higher by producing the executable specification for automating tests which can produce test coverage with enhanced reporting.