Cucumber Framework Important Notes
Feature files written in plain english
Cucumber is a testing tool that supports Behavior Driven Development (BDD). It allows writing tests in plain language, known as Gherkin, which is understandable by non-technical stakeholders.
Gherkin is the language used in Cucumber to define test cases. It uses a simple syntax to describe the behavior of an application in terms of features, scenarios, and steps
feature File structure:
Feature: Testing Login Functionality
Scenario: User logs in with valid Username and password
or
Scenario outline: User logs in with valid Username and password
Given user is on login page
And the user enter the “<username>” and “<2>” as below
|admin|admin| or |username|password| or |username|password|
|admin|admin|
And click on Login Button
then user should be logged in
Examples:
|username|password|
|Admin|SAngar|
|Admn1|sangar|
A Step Definition is a piece of code that matches a step in a Gherkin scenario. It defines the actions to be taken for each step in the scenario.
Cucumber tests can be executed using a Cucumber Runner class in JUnit or TestNG, or through Maven commands if it's integrated into the build process.
The Background keyword is used to define steps that are common to all scenarios in a feature file. These steps are run before each scenario.
Scenario: Used for a single test case with specific input data.
Scenario Outline: Used for a template scenario that runs multiple times with different sets of data, provided by the
Exampleskeyword.
Data-driven testing can be achieved using Scenario Outline with Examples or using Data Tables in the scenario steps.
Hooks in Cucumber (@Before, @After) are used to execute code before or after each scenario. They are commonly used for setup and teardown activities.Tagged hooks also we can use to run for particular scenario only.
The @CucumberOptions annotation is used to configure the Cucumber Runner class. It specifies the path to feature files, step definitions, reports, and other options like tags and plugin settings.
Failed scenarios can be rerun by using the rerun plugin in @CucumberOptions, which generates a text file with the paths of the failed scenarios. A separate runner class can then be created to execute these failed scenarios.
Tags are used to organize and control the execution of scenarios. You can include or exclude scenarios based on tags in the @CucumberOptions annotation or through command-line arguments.
Integration with Extent Reports or Allure can be done by adding the appropriate plugins in @CucumberOptions and configuring the reporting tool in your project (e.g., creating a listener class for Extent Reports).
Dependency injection in Cucumber can be managed using frameworks like PicoContainer or Spring. This allows sharing of state between step definitions and avoids tight coupling.
Parallel execution in Cucumber with TestNG can be managed by configuring the parallel attribute in the testng.xml file and adjusting the Cucumber Runner class to support parallel execution.
Considerations might include organizing feature files, implementing reusable step definitions, integrating with a reporting tool, setting up CI/CD integration, managing configuration properties, and handling parallel execution.
Implement retry logic, use hooks to capture screenshots on failure, and handle exceptions gracefully within step definitions.
Environment-specific data can be managed using property files, environment variables, or profiles in Maven, and accessed within step definitions or hooks.
Refactoring might involve breaking down complex scenarios, using scenario outlines, sharing state between steps with dependency injection, or modularizing step definitions.
Practices include writing clear and concise feature files, avoiding duplication, using backgrounds and hooks effectively, modularizing step definitions, and regularly reviewing and refactoring the test suite.
Cucumber:
Feature Files-->written in gherkin format
Feature level or scenario level we can provide tag
Feature-->says which functionality being tested
Scenario:--->says which scenario being tested such as valid input testing
Given--->User logged
when--->action to be performed
then--->assertions
BackGround-->Run before every scenario,,
order of execution is first Before hook will execute then background
Scenario outline-->Always followed by examples keyword..if we want to run the particular scenario for given set of inputs we can use this
Data table--->to run particular step multiple time based on given set of inputs we can use this
Single column--->dataTable.asList()--->List<String>
two column without header with multple rows--->dataTable.asLists()--->List<List<String>>
two column with one row wtih header--->dataTable.asMap()--->Map<String,String>
two column with more rows with header--->dataTable.asMaps()--->List<Map<String,String>>
directly we can pass parameter in feature file just by providing within double quotes“value“
Step Definitions:
Actual piece of code for each step in feature file will be impemented here
this is actually extending the baseclass
runner class:
Junit
Cucumber runner has below code
@RunsWith(Cucumber.class) @CucumberOptions(features="src/test/resources/FeatureFiles", glue={"stepDefinitions","hooks"},dryRun=true,monochrome=true,snippet,strict=true, plugin={"html:target/html.html", "io.qametta.allure.cucumber7jvm.allurecucumber7jvm","rerun:@Target/failed.txt", json:target/actualjson.json},tags="@Smoke and not @Regression") public class CucumberRunner{ } )
Testng
@CucumberOptions(features="src/test/resources/FEatureFiles", glue={"stepDefinitions","hooks"},druRun=true,Strict=false,monochrome=true,tags={} ,plugin="io.qameta.allure.cucumberjvm.allurecucumber7jvm", "rerun:@Target/failed.txt" ) ) public class CucumberRunner extends AbstractTestngCucumberTests{ }Features option used to mention the path feature file folder
Glue-->path of stepdefinitions,hooks package
plugin-->used to generate reports,rerun plugin used to generate failed scenarios in txt file
tags--->used to include exclude tags,ex: “@smoke” / @ Smoke and not @Re gression”
dryrun-->if it is true ,it used to generate the snippets
strict-->true means it run and check
monochrome=true,gives console in huma readable format
In testng, class has to extends AbstractTestngCucumberTests
In case of parallel testing, set parallel equal to tests with thread count and add below code in runner class
@Override @Dataprovider(paralle=true) public Object[] scenarios(){ return super.scenarios(); }for Rerun of failed tests,
@RunsWith(Cucumber.class) @CucumberOptions(features="@target/rerun.txt",glue="stepdefinitions")One more reporting is Cucumber reporting dependency,
public class CucumberReporting{ public static void generateReport(String json){ File file=new File(Location); Configuration conf=new Configuration(file,"Project name"); conf.addClassifications("name","Testname"); conf.addClassifications("OS","Windows 10"); List<STring> l=new ArrayList<String>(); l.add(json); ReportBuilder builder=new ReportBuilder(l,conf); builder.generateReports(); } }
publci class cucumberrunner{
@AfterSuite or @AfterClass
public void generateReport(){
CucumberReporting.generateReport("json file location");}
}ExtentReporter:
Junit
public ExtentReports reports;
public ExtentTest test;
@Before
public void setExtent(){
ExtentSparkReporter reporter=new ExtentSparkReporter("sangar.html");
reports=new ExtentReports();
reports.attachReport(reporter);
}
@Before("@Before scenario")
public void beforeScenario(Scenario scenario){
test=reports.createTest(scenario.getName());
}
@After
public void test(){
test.pass("Test passed")
test.fail(MediaEntityBuilder.createScreencapturefromPath();
}
@after
public void tear(){reports.flush()}
Hooks---@ before after annotations to perform some set of actions before and after every scenario
tagged hooks--->it helps to run particular hook for particular scenarios only
if we have multiple before,after we can use order=1,order=2 for before it is increament order,for after it is decrement order
if we have orders and with out order and tags,order of execution for before hooks is
for ex:one has order=10,one has @SMoke ,one dont have anything
now execution order is order=10,@smoke,finally the one whicih dont have anything
for After,one has order=10,one has @SMoke ,one dont have anything
now execution order is ,one dont have anything, @smoke ,order 10
@After
public void tearDown(Scenario scenario){
String screenshotPath = ScreenshotUtil.takeScreenshot(scenario.getName() + ".png");
if(scenario.isFailed()){
FileInputStream stream=new FileInputsteam(new File(screenshotPath ));
Allure.addAttachment("Screenshot",stream,)
}
}
Comments
Post a Comment