hhhameem/selenium-testng-allure-orangehrm

1. This repository is a Java-based UI test automation project for the OrangeHRM demo site. Its primary purpose is not to ship an application, but to execute browser-based acceptance tests and publish test evidence through Allure.

2. The execution stack is centered on Selenium 4.6 + TestNG, with Allure used for reporting and Faker used to generate realistic employee data. Gradle is the build and test runner, and the checked-in build/ and allure-* folders show previously generated outputs rather than core source.

3. The source layout is split into a minimal production tree and a richer test tree. src/main/java/org/example/Main.java is effectively a placeholder, while the actual automation architecture lives under src/test/java.

4. The test code follows a Page Object Model boundary. pages/LoginPage.java, pages/PIMPage.java, and pages/EmployeePage.java encapsulate browser interactions for login, employee creation/search, and personal information management, respectively. This keeps UI locators and action logic out of the runner classes.

5. setup/Setup.java is the central test bootstrap layer. It likely owns WebDriver lifecycle, browser/session initialization, and any preconditions shared by the tests. This is the main boundary between the TestNG runners and the browser automation layer.

6. testrunners/LoginTestRunner.java, EmployeeTestRunner.java, and PIMTestRunner.java are the executable test entry points. They map to the domain flows described in the README: dashboard verification, employee creation/search, login with created credentials, profile updates, and logout.

7. Test data is externalized in src/test/resources/Users.json. That makes credentials and user-related input separate from the test logic. The use of Faker suggests that at least part of the employee data is generated dynamically during execution rather than hardcoded.

8. Test orchestration is driven by TestNG suite files in src/test/resources/suites/ (LoginSuite.xml, EmployeeSuite.xml, PIMSuite.xml, and MasterSuite.xml). These define which runners or groups execute together, so the suite XMLs are the orchestration layer above the individual test classes.

9. utils/Utils.java is a shared support layer for cross-cutting concerns such as waits, assertions, data helpers, or file operations. In architecture terms, it sits below the runners and pages but above raw Selenium calls, reducing duplication across flows.

10. The repository is report-oriented. allure-results/ contains raw execution artifacts emitted by the test runs, while allure-report/ is the rendered Allure site with summaries, trends, categories, suites, and per-test case JSON. This shows a clear pipeline: TestNG execution produces results, Allure aggregates them into a browsable report.

11. The build/ directory confirms the standard Gradle lifecycle: compiled classes, test reports, and XML results are all generated there. The presence of build/test-results and build/reports/tests indicates the project also uses Gradle’s native test reporting alongside Allure.

12. From an architecture-diagram perspective, the main external dependency boundary is the OrangeHRM demo application at https://opensource-demo.orangehrmlive.com/. Everything else is internal scaffolding around that browser session: test suites trigger runners, runners call page objects, page objects interact with the site, and results flow into Allure and Gradle reports.