Review and Stretch Goals

If you've built the SecureBank suite and all 20+ scenarios are green, headless, parallel, and reported — you've completed the course. This lesson is the review: what you've built, what it proves, where the gaps are, and where to go next.

What you've built

Work through this checklist honestly. Each item represents a skill that will come up in interviews and on real teams:

Gherkin and BDD practice

• Feature files written in declarative business language — no CSS selectors or technical details in Gherkin
• Background used for shared preconditions instead of repeating Given steps
• Scenario Outline with Examples for data-driven scenarios (at least two features)
• Tags applied consistently: @smoke, @regression, @ui, @api, @wip
• At least one feature with 5+ scenarios that cover happy path, error cases, and boundary conditions

Architecture and code quality

• TestContext with no static fields — all state instance-scoped via PicoContainer
• Step definitions are thin — each method body is 1–3 lines delegating to a page object or Rest Assured
• Five page object classes — each owns the locators and interactions for one page
• BasePage or equivalent common helper (explicit waits, click helpers) shared across page objects
• Step definitions organised by domain (5 classes, not one monolith)

Lifecycle and reliability

• @Before("@ui") starts the browser; @After quits it even on failure
• Screenshot on failure attached to the Scenario object and visible in Allure
• No Thread.sleep() calls — all waits use WebDriverWait with ExpectedConditions
• Parallel execution passes at 4 threads with no race conditions

Reporting and CI

• Cucumber HTML report generated at target/cucumber-reports/report.html
• Allure report generated — interactive, with scenario detail and screenshots
• GitHub Actions pipeline runs on push, publishes the Allure report to GitHub Pages
• The published report URL is accessible without credentials — a product owner can check it

Honest self-assessment

For each item you couldn't tick: that's the next thing to work on. Common gaps and their fixes:

"I still have Thread.sleep() in some step definitions." Every Thread.sleep() is a ticking maintenance bomb — it works until the network is slow or the CI runner is under load. Replace with WebDriverWait.until(ExpectedConditions.visibilityOf(...)) in the relevant page object method. The Selenium with Java waits chapter covers this in depth.

"My step definitions are longer than 5 lines." Extract the excess into the page object. If the step definition contains a driver.findElement() call, that call belongs in a page object. Audit each step definition class and apply the rule: if it mentions a locator, extract it.

"Parallel execution fails with NoSuchSessionException." Run grep -r "static.*WebDriver\|static.*driver\|static.*RestAssured" src/test/java/ — any match is the root cause. Remove the static keyword; use TestContext instance fields instead.

"The Allure report shows steps but no screenshots for failures." Check that @After is in the glue path, uses io.cucumber.java.After (not JUnit's), and the MIME type is "image/png". Then deliberately fail a scenario and recheck.

"I didn't write Three Amigos scenarios — I just wrote what the code does." This is the collaboration gap. For one of your features, imagine you're presenting the feature file to a product owner. Ask them to confirm it covers their requirements. The questions they ask are the scenarios you're missing.

The stretch goals

The core capstone proves technical proficiency. These stretch goals push toward professional-level work:

Stretch 1: Serenity BDD

Serenity BDD is a framework built on top of Cucumber that generates richer living documentation — narrative reports with screenshots per step, not just per scenario. Replace allure-cucumber7-jvm with serenity-cucumber7 and serenity-maven-plugin. The feature files and step definitions are unchanged; the reports are significantly richer.

<dependency>
    <groupId>net.serenity-bdd</groupId>
    <artifactId>serenity-cucumber</artifactId>
    <version>4.1.20</version>
    <scope>test</scope>
</dependency>

Stretch 2: WireMock for API stubs

Real APIs are flaky in test environments — rate limits, latency, downtime. Replace the live API calls in your @api scenarios with WireMock stubs. Start a WireMockServer in a JUnit Platform @BeforeAll method (or a @BeforeSuite equivalent), configure stubs for each API endpoint, and run @api scenarios against http://localhost:8080. Tests become deterministic, fast, and runnable without network access.

Stretch 3: Pickles living documentation site

Pickles generates a searchable HTML documentation site directly from .feature files — no test execution required. Add the Pickles Maven plugin, run mvn pickles:generate, and get a static site where stakeholders can browse every feature and scenario. Host it on GitHub Pages alongside the Allure report.

Stretch 4: Cross-browser execution

Parameterise the browser choice:

String browser = System.getProperty("browser", "chrome");
switch (browser) {
    case "firefox" -> { WebDriverManager.firefoxdriver().setup(); return new FirefoxDriver(); }
    case "edge"    -> { WebDriverManager.edgedriver().setup(); return new EdgeDriver(new EdgeOptions()); }
    default        -> { WebDriverManager.chromedriver().setup(); return new ChromeDriver(options); }
}

Run: mvn test -Dbrowser=firefox. This is the pattern for cross-browser CI grids — each browser runs the @regression suite in a separate CI job.

Stretch 5: Cucumber + Spring Boot integration testing

If you have a Spring Boot application, cucumber-spring lets you @Autowire real production beans into step definitions for integration testing without a browser:

<dependency>
    <groupId>io.cucumber</groupId>
    <artifactId>cucumber-spring</artifactId>
    <version>7.18.0</version>
    <scope>test</scope>
</dependency>

Step definitions can inject @Autowired UserService userService and test business logic end-to-end through the actual service layer — faster than Selenium, more realistic than unit tests.

Where to go next

This course covered Cucumber BDD comprehensively. The natural next areas:

Selenium with Java — if you haven't already: the Selenium with Java course goes deeper on waits, Page Factory, actions, iframes, and cross-browser testing — all of which strengthen the Selenium layer under your BDD framework.

CI/CD and DevOps — your GitHub Actions pipeline is a start. The next steps are: multi-environment test runs (staging vs production), test result trend dashboards, and Slack/Teams notifications when the regression suite breaks.

API contract testing — Pact is the consumer-driven contract testing framework used alongside Cucumber API scenarios. It verifies that your API BDD tests match what the actual API provides, preventing integration breaks when services deploy independently.

Performance BDD — combining Cucumber with Gatling or k6 to verify that scenarios complete within SLA bounds under load. A Gherkin scenario that says "Then the dashboard should load within 2 seconds" can be tested at 100 concurrent users.

The single most important thing

The technical skills in this course — Gherkin syntax, PicoContainer DI, parallel execution, Allure integration — are learnable by anyone who reads the documentation carefully. They're table stakes.

The skill that separates a BDD practitioner from someone who runs Cucumber is the collaboration habit: holding Three Amigos sessions, reviewing feature files with product owners, publishing living documentation that non-developers actually read. That habit prevents the "Gherkin-as-test-wrapper" anti-pattern, where Cucumber adds complexity without adding shared understanding.

Write feature files that your product owner reads. Run them in CI. Publish the results. Repeat.

Your learning path from here