BDD with cucumber and gherkins using MindMap

 Business-Driven Development is a collaborative approach that focuses on aligning software development with business goals through the creation of executable specifications

Business driven development

Translating Business-Driven Development to executable specification in gherkins

Keywords and code blocks in Gherkins specification

• Feature is to provide a high-level description of a software feature.
• Rule is to represent one business rule that should be implemented
• Scenario or Example is a concrete example that illustrates a business rule
• Scenario Outline is used to run the same Scenario multiple times, with different set of data.

• Steps are used to define scenarios. steps can be:
• Given - describe the precondition of the system
• When - describes an event, or an action
• Then - describe an expected outcome, or result
• But - describe an outcome that is not expected
• There can be multiple steps of same type in a scenario.
• Background define a set of steps that are common to all scenarios in a feature file. Execution is after each scenarios
• Hooks are blocks of code that run before or after certain events. they are defined by annotation "@Before" and "@After" annotations. these are setup() and teardown() code in the application.

Understanding components of a cucumber framework

Components of a cucumber framework

Feature File:

• File corresponding to a feature/rule
• Can have multiple scenarios/examples, scenario outline and background.
• Annotations can be used to group tests, e.g: smoke, nightly, regression

Step definition File

• For given, when then, but steps defined in feature file, the logical code is written in a step definition file.
• Annotation @Given, @then are used to match the step definition method with the one provided in feature file

TestRunner File to execute tests

• TestRunner file defines the tests to be executed,

Components of a Test Runner File:

• Annotations: uses annotations from testing frameworks like JUnit or TestNG to define its purpose and behavior.
• Glue: specifies the package where Cucumber can find the step definitions
• Features: feature files which needs to be executed
• Plugins: defines the reporting path, tags and formatting.

References :

https://www.linkedin.com/learning/cucumber-essential-training

https://cucumber.io/docs/gherkin/reference/

Understanding and Implementing Rest Assured using workflows and MindMap

Understanding Rest API

A REST API (Representational State Transfer Application Programming Interface) is a set of rules and conventions for building and interacting with web services.

Below diagram show the principles/workflow and response status code for Rest API.

Key Components of Rest API

1. Endpoint: This is the URL where the API can be accessed. Each endpoint corresponds to a specific resource or collection of resources.

2. HTTP Methods: These define the action to be performed on the resource. These are also known as CRUD (create, request, update and delete) operations

- GET: Retrieve data from the server.

- POST: Send data to the server to create a new resource.

- PUT: Update an existing resource with new data.

- DELETE: Remove a resource from the server.

3. Headers: These provide additional information with the request or response. Common headers include Content-Type (indicating the media type of the resource) and Authorization (containing credentials to authenticate a user).

4. Parameters: These are used to modify the request. They can be included in the URL (query parameters) or in the request body.

5. Request Body: This contains the data sent to the server when making POST or PUT requests. It's typically formatted in JSON or XML.

6. Response Codes: status of the request.

Common Crude actions/verb and response status code mapping

Understanding Rest Assured

REST Assured is an open-source Java-based library designed for testing and validating RESTful web services. It integrates well with testing frameworks like TestNG and JUnit. Below are key things, we will discuss in the article to keep it short and refresher only.

Basic Workflow for getting response from Rest requests for different verbs

Basic Workflow for getting response from Rest requests for different verbs

Code Understanding for basic operations 

How to Fit Rest-Assured tests in Framework

MindMap for basic framework with rest assured

Please comment, in case any observations/queries in understanding the process and documentation

Reference for learning :

Rest API - https://www.ibm.com/docs/en/mfci/7.6.1?topic=apis-rest-api

JSON cheat-sheet - https://codebeautify.org/json-cheat-sheet

JSONpath cheat-sheet - https://gist.github.com/mackoj/5786f8b95da0a82e8e003f444c4295bf

Understanding hamcrest :

https://www.baeldung.com/java-junit-hamcrest-guide

That's all for this article.Please comment, in case any observations/queries in understanding the process and documentation

Understanding Page Object Model using workflows and examples

Page Object Model: Overview and Benefits

Page Object Model (POM) is a design pattern used in Selenium automation testing to enhance test maintenance and reduce code duplication.

Key concepts of Page Object Model:

Code Reusability:  Page Objects separate the test logic from the UI logic, promoting reuse of code across multiple tests.

Code Maintainability: Changes to UI elements identifiers are updated within the Page Object resulting minimal impact on test classes.

Improves Test Structure: Tests become more readable and easier to maintain as they interact with methods exposed by Page Objects rather than dealing with raw Selenium commands.

Reduces Duplication: Common interactions with elements (like clicking a button, entering text, etc.) are encapsulated within methods of Page Objects, eliminating redundant code in tests.

Scalability: Supports scaling of automation efforts by providing a structured approach to managing page interactions.

Page Object Model - Workflow

Components of Page Object Model (POM)

Page Object Model

Page Objects 

• Classes that encapsulate the behavior and structure of a web page.
• Each page in the application under test has its own corresponding Page Object class
• Page Objects interact with the page elements (like button, input) and provide methods to perform actions on these elements
• A Page class has:
• Identifiers of elements in the Page.
• methods to work with the identified elements in the page

Page Object Factory

• Page Factory is a concept in POM that initializes elements of a Page Object.
• It uses annotations (@FindBy) to locate elements on the web page.
• These annotations are used in Page Object classes to find and initialize WebElement objects.

BasePage Class

• This class serves as a foundational class that other Page Objects inherit from. 

• Examples of common functionality that are shared across multiple Page Objects and should be defined in BasePage class includes:

• WebDriver Initialization - Initialize the WebDriver instance in the base Class, so that it is used in the page Objects

• Common Page Actions - Define reusable methods for common actions that occur across multiple pages.

• Common Page Interactions: methods for handling common interactions  across different pages like handling alerts, executing JavaScript.

• Wait Mechanisms: Implement methods for waiting and waiting strategies to be used across pages

Any additional method that might be beneficial across multiple Page Objects.

Relation between Test Class and Page Class

Base Class with logic for common implementations

Creation of Page class extending the Base class

Implementation of the Page Class in Test class