Too much heat! Cool it with a framework using Cucumber...

Many QA folk sometimes find themselves under too much heat when the dev's behavior towards them gets more condescending and the product team's behavior gets more skeptical towards them. One of the main reasons is the lack of understanding of testing related processes, perspectives and goals. A pointless way of dealing with that heat is assigning extra unrelated work to QA team assuming they are jobless like cleaning the toilets or assign freshly created production issues RCA (Root Cause Analysis) to QA without atleast giving them read access to codebase, database and the help of client supporting teams while they are already dealing with a heavy workload which can cause burnouts.

Some not so pointless ways to fix the heat can be:

• Having a team of dedicated QA to handle RCA
• Using the collaborative concept of Behavior Driven Development (BDD)

The tool I have chosen to implement BDD is Cucumber. Even I have received some heat because I have not been using a framework to package my code from my previous articles and I have decided to build a framework with Cucumber to cool it down.

The benefit of packaging a project in a framework is to provide readability, reusability and handle complexity atleast in my case. One of the most important aspects of a framework which provides all the above qualities are Design Patterns. You can learn more about them here. I have used the following design patterns to build this framework:

1. POM (Page Object Model)
2. Singleton
3. Builder

Before we dive into the framework, let's get a brief understanding of BDD. It focuses on the collaborative work of developers, testers, and non-technical or business participants in a software project. BDD encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave, interesting right? Now let's focus on how to implement BDD in cucumber. There is a language called Gherkin which makes it happen.

• Gherkin is a human-readable language used in Cucumber, to define application behavior in a structured format.
• Given/When/Then are the core keywords or as I call them, the holy trinity of Gherkin.
• The test scenarios and their steps are defined using the above keywords and saved in a .feature file which can be run individually or by using a runner library like testNG or Junit.

You can learn more about cucumber and BDD in the links below:

• https://school.cucumber.io/collections
• https://cucumber.io/docs/

Now let's check out the framework starting with the project structure. Drumrolls ??

Presenting you, a framework housing both UI and API automation scripts driven by Cucumber BDD. Project Resilience!

|   .classpath
|   .project
|   pom.xml
|   project_structure.txt
|   testng.xml   
+---src
|   +---main
|   |   +---java
|   |   |   +---api
|   |   |   |   +---apiui
|   |   |   |   |       ApiUIEndpoints.java
|   |   |   |   |       
|   |   |   |   +---genai
|   |   |   |   |       GenAIEndPoints.java
|   |   |   |   |       GenAIServices.java
|   |   |   |   |       
|   |   |   |   +---uiapi
|   |   |   |           UIAPIEndpoints.java
|   |   |   |           
|   |   |   +---base
|   |   |   |       Base.java
|   |   |   |       client.properties
|   |   |   |       credential.json
|   |   |   |       GoogleServiceActions.java
|   |   |   |       Listeners.java
|   |   |   |       Property.java
|   |   |   |       Support.java
|   |   |   |       
|   |   |   +---pages
|   |   |       +---APIUICookieIntegration
|   |   |       |       OrangeHRMLeaveRequestPage.java
|   |   |       |       OrangeHRMLeavesPage.java
|   |   |       |       OrangeHRMLoginPage.java
|   |   |       |       
|   |   |       +---UIAPICookieIntegration
|   |   |               RahulShettyAcademyPage.java
|   |   |               SimpleFormAuthPage.java
|   |   |               
|   |   +---resources
|   +---test
|       +---java
|       |   +---runner
|       |   |       TestRunner.java
|       |   |       
|       |   +---stepdefinitions
|       |           APIUIStepDefinition.java
|       |           GenAIStepDefinitions.java
|       |           UIAPIStepDefinitions.java
|       |           
|       +---resources
|           |   testData.properties
|           |   
|           +---features
|                   apiui.feature
|                   genai.feature
|                   uiapi.feature        

I'm not going to bore you explaining the code, but I will give a brief walkthrough of the structure. Let's begin with the features folder located in src\test\resources\features

I've converted the code from my last 3 articles into features

All these feature files are connected to test scripts also called as step definitions located in src/test/java/stepdefinitions package.

The step definitions are connected to the feature files using TestRunner class located in src\test\java\runner package.

The project base, credential files, utility classes are placed in src\main\java\base package

The API's used by RestAssured and Jackson are placed in src\main\java\api package.

The page factory classes used by selenium are placed in src\main\java\pages package

See the framework in action here:

GitHub repo: vinayviga/resilience: framework built from mistakes (github.com)

Happy Exploring!!

PS:

• This project is a work in progress, and I intend to keep adding more to it
• If you came across the article and liked it, do send me a message connection request, suggestions are welcome ??
• I have used Thread.sleep() only for dramatic pause for the video recording.
• I could have written my sob story as a post in LinkedIn and could have asked for job references, however I refrain from that approach. Instead, I share what I have learnt and put forth my effort. Do reach out if you have or know of an opportunity in case you think or feel that I, the test engineer who wrote this, and a few other articles is worth it.

Do check out my other articles and stay tuned for more. Thanks for reading.