Inspiration
E-commerce teams ship new checkout flows, product pages, and promotions constantly — and every release risks quietly breaking login, cart, or checkout for real customers. Manually re-clicking through those flows before every deploy doesn't scale, and it's exactly the kind of repetitive, error-prone work that automated testing exists to solve. I wanted to move past reading about Selenium and TestNG and actually build the thing QA engineers build in production: a maintainable regression suite against a real, live web store — demoblaze.com — instead of a toy sandbox page with no real interactivity.
(This paragraph is a placeholder built from what the repo shows — swap in your real motivation if it's different.)
What it does
The framework drives a real Chrome browser through the core shopper journeys on a live e-commerce site and reports the result as a shareable HTML dashboard:
Sign up / Sign in — account creation and authentication Home & Index — storefront rendering, logo, page title, category navigation Product — product detail page and "add to cart" Cart & Cart Details — verifying items, prices, and totals persist correctly
Each run is grouped into Smoke, Sanity, Regression, and Cross-Browser suites (Chrome / Firefox / Edge), so the same test code answers two different questions: "did I just break something critical?" (smoke, seconds) and "is everything still correct?" (regression, full pass).
How I built it
The architecture follows the Page Object Model (POM):
PageObjects/ — one class per screen (IndexPage, LoginPage, SignInPage, HomePage, ProductPage, CartPage, CartDetailsPage) TestScripts/ — one TestNG test class per page object, 1:1 with the UI it exercises Base/BaseClass — a single ThreadLocal shared across tests, so parallel execution (thread-count="5") doesn't leak state between threads Utility/ — Log (Log4j), ExtentManager (Extent Reports), and a TestNG ITestListener for screenshots on failure
Stack: Selenium WebDriver 4, TestNG 7, WebDriverManager, ExtentReports 4, and Maven Surefire wiring it into mvn test -DxmlFiles=.xml.
If $T_m$ is the time a person needs to manually click through sign-in → browse → add-to-cart → verify-cart, and $T_a$ is the automated smoke suite's runtime, the value of automating it scales with runs per day, $n$:
Time saved per day = 𝑛⋅(𝑇𝑚−𝑇𝑎) Time saved per day=n⋅(Tm−Ta)
Running the actual smoke suite end-to-end (5 tests) against the live site took 51.967 seconds — something that takes a human tester several minutes to click through by hand, every time, before every deploy.
Challenges I ran into A dependency-scope bug that broke the build from a clean clone. pom.xml declared TestNG with test, but BaseClass.java lives in src/main/java and uses @BeforeSuite/@AfterSuite. Maven compiles main before test, so test-scoped dependencies aren't visible there — the build failed with dozens of "package org.testng does not exist" errors. Fixed by removing the scope restriction. Chrome outpacing Selenium's DevTools protocol mappings — Unable to find CDP implementation matching warnings against very recent Chrome builds. Testing a site I don't control — demoblaze.com's markup and timing can shift without notice, so locators and waits need to be resilient, not brittle-precise. Keeping parallel runs thread-safe — sharing one WebDriver across five concurrent threads corrupts state unless each thread gets its own instance, hence ThreadLocal. What I learned Why POM earns its complexity: a markup shift on one page means editing one class, not every test that touches it. How TestNG groups let one suite serve both a 60-second pre-deploy check and a full nightly regression pass. That Maven dependency scope constrains where in the source tree a class can live — get it wrong and the build failure looks unrelated to the real cause. How to treat an Extent/TestNG HTML report as a real deliverable a non-technical stakeholder can trust, not just console noise.
Log in or sign up for Devpost to join the conversation.