Get your test automation framework in top shape!
Reap the automation benefits from a collaborative Cucumber framework
Setting up a Cucumber framework is easy, that’s what its for. But setting up a maintainable framework to maximize the potential of Cucumber can be a bit more demanding.
I worked with Cucumber before I even heard of BDD, later on I started diving into the world of BDD and started forming a picture on how the use Cucumber more effectively. In my work I’ve seen Cucumber frameworks in Java, C#, Ruby, the feature files written in Dutch, the Given When Then’s all over the place, the steps describing a single click and even frameworks to do API testing only. What do they all have in common? They worked! No matter how different they were, they all worked. Through my experience I’ve now come to clear picture on how to implement Cucumber as not only a technical tool but also a tool to help other testers grow in their technical field. I want to inspire people to take a step back and evaluate their own framework, inspire people to start using Cucumber and even learn from my mistakes during my awesome journey.
When building a frame work it is always a good idea to split the difference between “What are we testing in our application” vs “How are we testing our application”. This split is always an excellent start to think about placement of complexity in the code.
We are testing a checkout flow on an e-commerce platform (What)
We are testing with Selenium WebDriver (How)
What are you testing should live on the outer layer (feature files) of your framework. How are you testing should live in the inner layer of your framework (POM code)
With the notion of “What vs How” we can not only draw a picture with code complexity, but we can now also assign skill levels to the layers:
Top – lots of people can write scenario’s describing what is tested in a test.
The bottom – Experienced engineers should setup the Object Oriented Code calling Selenium WebDriver
But what about the middle? This gray area is where both worlds meet, the step definitions. Let’s call it the assertion zone. The actual “what we test” (in this example an assertion) should not be placed in the “how code” itself. This for example will set the code in stone for only 1 particular situation.
When we have a look at the amount of people whom can tackle a specific layer, we get an upside-down pyramid. Large base on the top where a lot of people can contribute and a smaller point at the bottom where probably only a few people can actually setup the POM code from scratch. During my workshop we will have a closer look at the code on all three levels.
With my workshop I want to show the audience which key features (no pun intended) can not only benefit a Cucumber framework but can elevate a Cucumber framework to the next level. Through my workshop I want share my own experiences, both good and bad. What made cucumber so successful for me when working in a team and what made me choose the tool even though I was working alone as an automation specialist in a team. The audience will get hands-on experience on how powerful a Cucumber framework can be when used with team wide collaboration in mind.