Project Brief — BDD Test Suite for an Online Banking Application

The capstone project is a full Cucumber BDD test suite for SecureBank — a fictional online banking application. You'll apply every technique from the course: Gherkin written at the business level, step definitions backed by page objects and Rest Assured, PicoContainer for shared state, tagged execution, parallel scenarios, and published reports.

This lesson is the brief. Lesson 2 walks through the build with complete code. Lesson 3 is the self-review and stretch goals.

The application under test

SecureBank is a web-based banking application with five testable feature areas:

Authentication — login with username and password; session management; logout; locked accounts after 5 failed attempts.

Account Overview — display balance for savings and current accounts; currency formatting; last transaction date.

Fund Transfer — transfer between own accounts; transfer to a third party by account number; validation for insufficient funds, invalid account numbers, and self-transfer.

Transaction History — paginated list of transactions; filter by date range; filter by type (credit/debit); export to CSV.

Bill Payment — add a payee by reference number; schedule a one-time payment; schedule a recurring payment; cancel a scheduled payment.

You'll build a BDD test suite that covers all five areas with realistic, stakeholder-readable scenarios.

The deliverables

By the end of the capstone you'll have built:

1. A Maven project with the full dependency set:

cucumber-java 7.18.0
cucumber-junit-platform-engine 7.18.0
junit-platform-suite
cucumber-picocontainer 7.18.0
selenium-java 4.21.0
webdrivermanager 5.9.1
rest-assured 5.4.0
allure-cucumber7-jvm 2.25.0
maven-surefire-plugin 3.2.5

2. Five feature files — one per feature area, totalling at least 20 scenarios:

authentication.feature — 5 scenarios (happy path, wrong password, locked account, session timeout, logout)
account-overview.feature — 3 scenarios (balance displayed, multiple accounts, zero balance)
fund-transfer.feature — 5 scenarios (own accounts, third party, insufficient funds, invalid account number, self-transfer)
transaction-history.feature — 4 scenarios (all transactions, filter by date, filter by type, export)
bill-payment.feature — 4 scenarios (add payee, one-time payment, recurring payment, cancel)

3. Step definition classes organised by domain:

stepdefinitions/
├── AuthSteps.java
├── AccountSteps.java
├── TransferSteps.java
├── TransactionSteps.java
└── BillPaymentSteps.java

4. Page object classes for each UI page:

pages/
├── LoginPage.java
├── DashboardPage.java
├── TransferPage.java
├── TransactionHistoryPage.java
└── BillPaymentPage.java

5. A TestContext class (PicoContainer-injected) holding:

WebDriver (lazy initialisation with headless flag)
RequestSpecification for Rest Assured API calls
String lastCreatedAccountId for cross-step ID passing
Response lastApiResponse for API assertion steps

6. A Hooks class with:

@Before("@ui") — browser setup
@Before("@api") — Rest Assured base URI and request logging
@After — screenshot on failure + driver quit

7. Tagged scenarios with consistent convention:

@smoke on the single most critical scenario per feature
@regression inherited at the Feature level for all scenarios
@ui on all browser-based scenarios
@api on all Rest Assured-based scenarios
@wip on any in-progress scenarios (excluded from CI runs)

8. Data-driven scenarios using Scenario Outline + Examples for at least two features (login with various credential types; fund transfer with various amount edge cases).

9. Reporting configured to produce:

html:target/cucumber-reports/report.html
json:target/cucumber-reports/report.json
Allure results at target/allure-results/

10. A GitHub Actions CI pipeline that runs the suite on every push to main, publishes the Allure report, and fails the build if any @regression scenario fails.

Acceptance criteria for the capstone

Your suite is complete when:

mvn test -Dcucumber.filter.tags="@smoke" runs in under 3 minutes and all smoke scenarios pass
mvn test -Dcucumber.filter.tags="@regression and not @wip" -Dheadless=true runs all 20+ scenarios green
mvn test -Dcucumber.filter.tags="@regression and not @wip" -Dheadless=true -Dcucumber.execution.parallel.enabled=true -Dcucumber.execution.parallel.config.fixed.parallelism=4 runs green with no race conditions
The Allure report shows each feature and scenario with steps and any attached screenshots
A product owner could read any feature file and confirm it accurately describes how SecureBank should behave

A note on test targets

SecureBank doesn't exist as a live application. For the capstone you have two options:

Option A — use an existing practice application. Sauce Demo covers login and product browsing. The Internet covers many Selenium patterns. Parabank is a banking demo that covers login, balance, transfers, and bill payment — the closest match to SecureBank's feature set. The walkthrough in Lesson 2 uses Parabank.

Option B — use WireMock or a local mock server for API scenarios. If you prefer to work API-first, set up WireMock to stub the SecureBank REST API and write @api scenarios against the stubs.

The scenarios and step definitions are the same either way. The page object locators will differ from application to application — the walkthrough in Lesson 2 uses Parabank locators, but the architecture is what matters, not the locators.

Capstone deliverables overview

SecureBank BDD Suite

– authentication.feature
– account-overview.feature
– fund-transfer.feature
– transaction-history.feature
– bill-payment.feature

– TestContext (PicoContainer DI)
– Page Objects (5 pages)
– Step Definitions (5 classes)
– Hooks (Before/After)

– @smoke — 5 scenarios
– @regression — 20+ scenarios
– Headless CI mode
– 4-thread parallel execution

Cucumber HTML report –
Allure interactive report –
GitHub Actions CI –
Published living docs –

Suggested build order

Build the capstone in layers. Don't try to build all five features at once.

Phase 1 (1–2 hours): Maven setup + TestContext + Hooks + authentication.feature. Get one smoke scenario green with Selenium and PicoContainer.

Phase 2 (1–2 hours): account-overview.feature + AccountSteps + DashboardPage. Add the @api tag to one API-verifiable scenario and wire Rest Assured.

Phase 3 (2–3 hours): fund-transfer.feature + TransferSteps + TransferPage. This feature has the most edge cases — Scenario Outline with Examples for the data-driven transfer validation scenarios.

Phase 4 (1 hour): transaction-history.feature + bill-payment.feature. These build on top of the already-established architecture.

Phase 5 (1 hour): reporting (Allure configuration), tagging audit (@smoke on the right scenarios), parallel execution testing (confirm no static state).

Phase 6 (1 hour): GitHub Actions CI pipeline. Confirm it runs headless, publishes the Allure report, and fails correctly when a scenario is broken.

Before you start

Check the prerequisites are in place:

Java 17+ (java -version)
Maven 3.6+ (mvn -version)
IntelliJ or VS Code with Java support
Chrome installed (for Selenium; WebDriverManager handles chromedriver)
Git repository initialised
Allure CLI installed (allure --version) or plan to use the GitHub Actions Allure plugin

The walkthrough in Lesson 2 assumes you're starting from an empty Maven project. If you built the practice projects from Chapters 1–4, you can extend one of those — but a fresh project is cleaner for portfolio purposes.

Next lesson: the guided walkthrough — complete code for all five features, step by step.