SauceDemo Automation Framework

A Java-based test automation framework built for the Ejada Senior Automation Tester assignment, covering both UI and API testing.

Tech Stack

Layer	Tool
Language	Java 17
UI Driver	Selenium WebDriver 4
BDD	Cucumber (Gherkin)
Test Runner	TestNG
API Testing	RestAssured
Driver Mgmt	WebDriverManager (auto binary download)
Reporting	ExtentReports (Spark HTML) via Cucumber adapter
Build Tool	Maven

Project Structure

src/test/java/com/ejada/automation/
├── api/                 -> RestAssured API tests (Simple Books API)
├── base/                -> DriverFactory (thread-safe, cross-browser) + BasePage
├── pages/                -> Page Object Model classes (Login, Inventory, Cart, Checkout)
├── runners/              -> Cucumber-TestNG runner
├── stepdefinitions/      -> Step definitions + Hooks (driver lifecycle, screenshot on failure)
└── utils/                -> ConfigReader

src/test/resources/
├── features/             -> .feature files (Gherkin scenarios)
├── config.properties     -> Base URLs, credentials, browser, timeouts
├── testng.xml            -> Parallel cross-browser + API suite config
├── extent.properties     -> ExtentReports adapter config
└── spark-config.xml      -> Report theme/branding

What's Covered

UI (saucedemo.com)

• Login: valid login, invalid credentials, locked-out user, empty username/password (via Scenario Outline)
• Full order flow: add product to cart → checkout → fill shipping info → finish → verify confirmation
• Cross-browser: Chrome + Firefox, configured externally in config.properties / overridable via -Dbrowser=
• Parallel execution: TestNG runs Chrome and Firefox suites concurrently, and scenarios within each browser run in parallel threads (thread-safe via ThreadLocal<WebDriver>)

API (Simple Books API)

• GET /status, GET /books, GET /books/{id}
• POST /api-clients to generate a bearer token, then POST /orders using that token
• PATCH /orders/{id} to update an order, with a follow-up GET to verify the change
• DELETE /orders/{id}, with a follow-up GET asserting a 404

Prerequisites

• Java 17 (JDK)
• Maven (bundled with IntelliJ, or install separately)
• Google Chrome and Mozilla Firefox installed locally
• Git

No need to manually download chromedriver/geckodriver — WebDriverManager resolves and downloads the correct version automatically at runtime based on your installed browser version.

Running the Tests

Run everything (UI on both browsers in parallel + API suite), via the TestNG suite file:

mvn clean test

Run only Chrome:

mvn clean test -Dbrowser=chrome

Run only Firefox:

mvn clean test -Dbrowser=firefox

Run headless (useful for CI):

mvn clean test -Dheadless=true

Run only a specific Cucumber tag (e.g. just smoke tests):

mvn clean test -Dcucumber.filter.tags="@smoke"

Viewing Reports

After a run completes, open:

test-output/ExtentReport/SparkReport/Spark.html

This gives a full HTML report with pass/fail breakdown per scenario, and embedded screenshots for any failed UI step (captured automatically via the Cucumber Hooks class).

Cucumber's own basic HTML/JSON output is also available in target/cucumber-reports/ if needed for CI integrations.

Design Notes

• Page Object Model: every page interaction lives in a pages/*Page.java class extending BasePage, which centralizes explicit-wait logic. Step definitions never touch Selenium locators directly.
• Thread safety: DriverFactory uses a ThreadLocal<WebDriver> so that parallel TestNG threads (different browsers, or parallel scenarios within a browser) never share or clobber each other's driver instance.
• Config externalization: browser choice, base URLs, and test credentials are all in config.properties, with system property overrides (-Dbrowser=...) taking precedence — no hardcoded values in test logic.
• API test ordering: the Simple Books API tests are intentionally sequential (priority + dependsOnMethods) since order creation depends on a freshly generated token, and the PATCH/DELETE tests depend on that order existing. This keeps the flow readable rather than artificially independent.

Known Limitations / Next Steps

• The empty-username/empty-password login scenarios use a Scenario Outline; if SauceDemo ever changes its exact error copy, only the Examples table needs updating.
• Extent/Allure reports and test-output/, target/ are gitignored — they're generated artifacts, not source.
• For CI (GitHub Actions, Jenkins, etc.), add -Dheadless=true to the Maven goal so Chrome/Firefox run without a display.