Featured project 1 · Java · UI, API, database
Enterprise Test Automation Framework
A production-style test automation platform: UI, API, database, integration and end-to-end tests of one application, with parallel execution, evidence-rich reporting, Docker + Selenium Grid and GitHub Actions pipelines.
Purpose
Shows how a test platform for a real product is designed, built, documented and operated, not just a test suite. It tests ShopEase Admin, a small shop back office kept in the same repository, so one business record can be checked through the UI, the REST API and the database. It is a portfolio project, not a framework running in a company.
Technology stack
| Area | Tools |
|---|---|
| Language / build | Java 17, Maven (multi-module) |
| Test runner | TestNG 7.12 |
| UI | Selenium 4 (local and Selenium Grid) |
| API | REST Assured 6, Jackson, JSON Schema validation |
| Database | JDBC (H2), parameterised queries |
| Assertions / data | AssertJ, Datafaker, JSON and CSV files |
| Logging / reporting | SLF4J + Logback per thread and test; Allure 3 |
| Containers | Docker, docker compose, Selenium Grid (hub + Chrome, Firefox, Edge nodes) |
| CI/CD | GitHub Actions, Dependabot, dependency review, Checkstyle |
Architecture overview
Layers depend downwards only: tests contain no Selenium, HTTP or SQL. The repository documents the architecture in docs/architecture.md and 21 architecture decision records in docs/adr.
Layers and responsibilities
| Layer | Responsibility | Examples |
|---|---|---|
| Tests | What is checked, in business terms; no Selenium, HTTP or SQL | tests/api, tests/ui, tests/db, tests/integration, tests/e2e |
| Pages, API services, DB queries | One class per screen, API resource or query area; the only place that knows locators, endpoints and SQL | page objects, service objects, query classes |
| Components and clients | Reusable UI components, the REST client, the query executor, waits on real state | ApiClient, QueryExecutor, components |
| Driver and configuration | Browser per thread (local or Grid), layered configuration, secrets from the environment | DriverFactory, configuration loader |
| Execution and evidence | Retry policy for infrastructure failures, logging, Allure steps and attachments | listeners, SecretMasker, Allure |
Configuration and execution
Settings are layered: defaults, an environment (-Denv=qa), then system properties, so the same tests run on a laptop, in Docker, against Grid or in CI without edits. Examples: -Dbrowser=firefox, -Dthreads=4, -Dsuite=smoke, -Dexecution=remote -Dgrid.url=....
Parallel execution: one browser per thread, unique data per test, per-thread clean-up and logs; the full suite took about 242 s serial, 171 s with 2 threads and 148 s with 4 (clean clone).
Retries: only transient infrastructure failures (browser start-up, lost sessions, refused connections) are retried, for test methods and for browser start-up; assertion failures and wait timeouts never are, and every retry is visible in the report.
Reporting: Allure shows every UI action, API call (request and response attached) and SQL query as a step; failed UI tests get screenshot, URL, page source and browser console; failures are categorised (configuration, infrastructure, timeout, authentication, database, UI, API, assertion); logs mask secrets.
Key engineering decisions
- Test at the cheapest level (API) and check consistency across UI, API and database
- Every test owns its data: independent, parallel-safe, no order dependencies, no shared fixtures, no sleeps
- Retry only transient infrastructure failures (browser start-up, lost sessions, refused connections); assertion failures and wait timeouts never
- Every failure explains itself: steps, request/response, rows, screenshot, log, environment and build in the report
- Same tests everywhere: laptop, Docker, Grid and CI are configured, never edited
- Cloud device farms deferred on purpose; Grid covers remote browsers
Implemented features
- 169 TestNG test executions from 124 test methods (data-driven tests run once per data row), all passing in the scheduled nightly run of 12 Oct 2026; by package, without overlap: API 57, UI 48, database 13, integration 9, end-to-end 2, framework unit tests 40. Evidence: nightly run 38226623404
- Named suites (TestNG groups, which overlap): smoke 20, sanity 11, regression 121
- Parallel execution: one browser per thread; full suite about 242 s serial, 171 s with 2 threads, 148 s with 4 (clean clone)
- Allure report with every UI action, API call and SQL query as a step, failure categories and an environment panel
- Secrets masked in every log line, report attachment and failure message
- Docker compose: application, Selenium hub, Chrome/Firefox/Edge nodes and the test runner
Setup and execution
mvn clean test # full suite, local app, Chrome
mvn clean test -Dsuite=smoke -Dheadless=true # one suite
mvn clean test -Dbrowser=firefox -Dthreads=4 # another browser, 4 threads
docker compose -f docker/docker-compose.yml up --build --abort-on-container-exit --exit-code-from testsRequirements: JDK 17+, Maven 3.9+, Chrome or Edge; Node.js for the Allure CLI. Full instructions in the README.
Sample test results
CI workflow
Five workflows: CI on pull requests (compile with warnings as errors, Checkstyle, unit tests, smoke, dependency review), Main on every push (API, UI, smoke on Edge), Nightly (full suite on Chrome, regression on Firefox and Edge, and regression on Docker + Grid), plus report publishing and a manual suite runner.
Known limitations and future improvements
Limitations
- Cloud device farms are not integrated (deliberate, see the decision records)
- The application under test uses an in-memory H2 database and demo-grade security; it exists to be tested
- Allure steps are at user-action level; no business-level step names yet
Next steps
- BrowserStack or LambdaTest as another remote target
- Allure report with history on GitHub Pages
- Contract tests (OpenAPI) and performance smoke tests in the nightly run
- Accessibility checks (axe) on key pages
- PostgreSQL in Docker