hhhameem/tk_automation_java_appium

1. This repository is a Java-based mobile test automation project, not an application backend. The architecture is centered on running Appium-driven UI tests against a real Android device, with Selenium/Appium as the automation layer and Gradle as the build/test runner.

2. The production source tree is essentially empty: src/main/java/org/example/Main.java is present, but the real system lives under src/test. That means the important architecture is the test framework itself: setup, screen abstractions, test runners, suite orchestration, and fixture data.

3. The execution boundary is external:

- a real mobile device is required,

- Appium Server acts as the bridge to the device,

- the tests interact with the device’s native UI,

- Allure is used to render execution results after the run.

The README also makes clear the tests depend on device state, especially the phonebook/contact book.

4. Test bootstrap is isolated in src/test/java/setup/Setup.java. This is the framework entry point for preparing the Appium/Selenium session and any shared driver/runtime configuration used by the tests.

5. UI interactions are grouped into screen objects under src/test/java/screens:

- CashboxScreen.java

- RegistrationScreen.java

- TallyScreen.java

These are the main interaction boundaries between tests and the mobile UI, likely encapsulating locators and actions for each business flow.

6. Test execution is organized by scenario-specific runners in src/test/java/testRunners:

- CashboxTestRunner

- RegistrationTestRunner

- TallyTestRunner

- UnverifiedRegistrationTestRunner

Each runner likely binds one scenario family to one or more screen objects and test methods, keeping the flows separated by business area.

7. Suite orchestration is defined with TestNG XML files in src/test/resources/suites. MasterSuite.xml is the top-level coordinator, with dedicated suites for Cashbox, Registration, Tally, and Unverified Registration. The README notes that the default Gradle test command currently only runs the Tally tab unless MasterSuite.xml is edited, so suite selection is part of the execution architecture.

8. Test data is externalized in JSON fixtures under src/test/resources:

- users.json

- customers.json

This suggests the tests separate scripted interactions from data inputs, so scenarios can be driven by named user/customer records rather than hardcoded values.

9. src/test/java/utils/Utils.java is the shared helper layer. In this kind of framework, utilities usually hold reusable test support such as data loading, waits, formatting, or device helpers, acting as a cross-cutting dependency for runners and screens.

10. The runtime/tooling stack materially shaping the architecture is:

- Java 11+

- Gradle for build and test execution

- Selenium 4.x and Appium Java Client 8.x for automation

- Appium Server 1.22.x

- TestNG suite XML for orchestration

- Allure for reporting

These tools define how tests are composed, executed, and reported.

11. The repository has an important environmental dependency on device state: the tests require specific contacts already present on the phone. That means the system is not fully self-contained; it depends on preconditions outside the repo, which affects reproducibility and the reliability boundary of the automation.

12. In diagram terms, the main flow is:

suite XML -> test runner -> setup/driver initialization -> screen object actions -> Appium Server -> mobile device,

with JSON fixtures feeding the runners and Allure consuming execution output for reporting.