• TDD (Test Driven Development):
  • Focuses on writing test cases first, then developing the code to pass those tests.
  • Tests are written in programming language (Java, Python, etc.).
  • Mainly for developers.
• BDD (Behavior Driven Development):
  • Focuses on writing scenarios in plain English using Gherkin syntax (Given-When-Then).
  • Improves collaboration between developers, testers, and business stakeholders.
  • Uses tools like Cucumber, JBehave.

Key Difference: TDD tells how the code works (technical approach), whereas BDD tells how the application behaves (business approach).

• Cucumber is an open-source testing framework that supports Behavior-Driven Development (BDD).
• It allows writing test cases in plain English using Gherkin syntax (Given-When-Then).
• Integrates with tools like Selenium, JUnit, and TestNG for automation.
• Bridges the gap between business stakeholders and technical teams by making test cases readable by everyone.
• Commonly used with Java, but also supports other languages like Ruby, JavaScript, etc.

• A Feature File in Cucumber contains scenarios written in Gherkin syntax that describe the behavior of the application in plain English.
• It helps bridge the communication gap between business analysts, developers, and testers.
• Each Feature File consists of:
  • Feature
  • Scenario
  • Steps (Given-When-Then)

• Execution in Cucumber takes place from the Runner Class (Test Runner).
• The Runner Class uses:
  • @RunWith(Cucumber.class)
  • @CucumberOptions (to link Feature Files, Step Definitions, Tags, Reports, Plugins)
• Integrates with JUnit or TestNG for execution and reporting.

• Scenario:
  • Represents a single test case with fixed data.
  • Runs only once for the given steps.
• Scenario Outline:
  • Used for data-driven testing by running the same scenario with multiple sets of data.
  • Uses Examples table to provide values for placeholders.

• Scenario Outline:
  • Used for data-driven testing by running the same scenario with multiple sets of data.
  • Uses Examples table to provide values for placeholders.
• DataTable:
  • Used to pass a table of data to a single step, usually for multiple values in one scenario.
  • Does not repeat the scenario; instead the step reads multiple rows as input.

• By using Step arguments (quoted values) that are dynamic data passed from the feature step to the Step Definition.
• This makes the step reusable for multiple data sets without changing the code.

• Using Step arguments
• Using Scenario Outline with Examples Table
• Using DataTable without Header (List of List)
• Using DataTable with Header (List of Map)

• @RunWith(Cucumber.class) → Tells JUnit to run the tests using Cucumber’s test runner.
• @CucumberOptions → Used to configure the test execution.
  • Specifies locations of feature files
  • Specifies glue code (Step Definitions)
  • Configures tags, plugins (reports), and other options

• features: Path to the folder or file containing Feature Files.
• glue: Package name(s) containing Step Definition classes.
• tags: To filter which scenarios or features to run based on tags (e.g., @Smoke, @Regression).
• plugin / format: To specify report formats like pretty, html, json, junit, etc.
• monochrome: Makes console output readable by removing extra characters.
• dryRun: Checks if all steps have step definitions without actually running tests.

• Tags are used to execute or skip a group of scenarios in the feature file.
• We can apply tags on Feature or Scenario using @tagName.
• Tags are configured in @CucumberOptions to selectively run tests.

• Hooks are special methods that run before or after each scenario (or step) to set up or clean up test conditions.
• They help in reusing code for common preconditions like:
  • Launching browsers
  • Setting up test data
  • Closing resources
• Cucumber provides annotations like @Before and @After to define these hook methods.

• Cucumber HTML Report
• JSON Report
• JUnit / XML Report
• Cucumber JVM Report (HTML, supports attaching screenshots)