Directory Stucture

/target

The target folder in project is where Maven stores all the output generated during the build process. Here's a description of the directories inside the target folder:

• extent-report: This directory holds the HTML reports generated by the ExtentReports library, a popular reporting tool for Selenium Java projects. It will contain detailed logs, screenshots, and test execution results in a visually appealing format.

• maven-status: This folder keeps status information about the build process, such as which files were compiled, which tests ran, and their results. It helps Maven track what needs to be rebuilt on subsequent builds.

• surefire-reports: This directory contains reports generated by Maven Surefire Plugin. It includes XML and HTML reports of test execution results for each test case, which is useful for debugging failed tests and viewing overall test summaries.

• test-classes: This folder contains compiled .class files from your test code (src/test/java). All your Selenium test classes are compiled and stored here for execution.

In summary, the target folder is essential for storing compiled code, generated reports, and the output from the Maven build and test processes.

/src/test/resources

The resources folder in project contains various configuration files and directories essential for the proper functioning of your tests and reporting. Here's a description of each file/folder highlighted:

• apk: This contains APK files for mobile testing. APK files are used in mobile automation, especially for Android testing with tools like Appium.

• configs.properties: This file contains general configuration settings for your test execution, other test-related settings.

• env-configs.properties: This file specific to environment-related configurations. It store environment variables, such as dev, staging, or production environment details, which can be loaded dynamically during test execution.

• env-configs.properties.default: This file is a template or default version of env-configs.properties. It contain default environment settings, which could be copied or referenced when setting up different environments.

The resources folder is typically used to store non-code assets such as configuration files, test data, and other resources that your test framework may need during execution.

/src/test/java/core

The core folder contains the foundational code that supports the entire test automation framework. Here's a breakdown of the subfolders and files within the core folder:

Subfolders:

1. abstractclass: This folder contains abstract classes that define common methods or behaviors shared by multiple classes in the framework. Abstract classes can provide reusable code and enforce specific structure for inherited classes.

2. driver: This directory contains classes related to WebDriver management, such as initializing browser drivers (ChromeDriver, FirefoxDriver, etc.), setting capabilities, and managing WebDriver lifecycle during tests.

3. utilities: This folder contains utility classes that provide helper methods to be used throughout the framework. These could be functions for handling date formats, reading from files, generating random data, or any other commonly used operations.

4. verify: This folder seems to hold classes responsible for verification tasks, such as asserting conditions, comparing actual versus expected results, and logging test failures or successes.

Files:

1. Global.java: This file holds global constants or variables that are used throughout the framework. It may contain paths, URLs, or configurations that are accessed from multiple locations in your tests.

2. PropertiesReader.java: This file handles reading from .properties files (like configs.properties). It may load configurations such as URLs, browser types, and environment variables into the test framework.

3. Report.java: This class generate test reports, recording the test execution results. It responsible for integrating with reporting tools like Allure or ExtentReports.

4. TagEnum.java: This class defines tags as enumerations, which be used for organizing or filtering tests based on specific tags or categories (e.g., smoke tests, regression tests).

Summary:

The core folder houses the essential components that form the backbone of the test automation framework. It includes configuration readers, logging mechanisms, WebDriver management, utility classes, and verification mechanisms, making it a crucial part of the Selenium Java setup.

/src/test/java/features

The features folder is where you store the feature files used for writing test scenarios in Gherkin syntax (typically used with Cucumber). Here's a breakdown of the contents:

Subfolders:

1. Demo: This folder contains feature files related to demo tests. Inside the Demo folder, there are specific subfolders for various platforms or functionalities:

• Android: This subfolder contains feature files related to Android mobile automation tests, focusing on testing Android applications or web testing on Android devices.
• Goggle: This folder contains feature files related to testing Google search.

2. Linagora\Tmail: This folder pertains to the Linagora/Tmail platform. Inside it:

• Mobile: Contains feature files specific to mobile platform testing, an mobile versions of Tmail.
• Web: Contains feature files related to web-based testing, focusing on testing the Tmail web application.

Summary:

The features folder is used to organize your Cucumber feature files, which define test scenarios in plain language (Gherkin). Each subfolder categorizes the feature files based on the platform (e.g., Android, Mobile, Web) or specific application (e.g., Tmail). These feature files are the blueprint for automated tests executed using Selenium.

src/test/java/hooks

The hooks folder contains classes that define actions to be taken before or after the execution of certain test scenarios. These "hooks" are typically used in Cucumber to set up and tear down test environments. Here's a breakdown of the folder structure:

Subfolders:

1. api:

• Hooks.java: This file contains hook methods related to API testing. These methods are likely responsible for setting up or cleaning up any resources or configurations before and after API tests. For example, it could involve preparing API requests, authenticating tokens, or cleaning up mock data after the tests run.

2. webdriverio:

• Hooks.java: This file defines hooks specific to WebDriverIO, which is used for handling browser automation. The hooks in this file might involve browser setup (e.g., opening a browser, setting up timeouts) or teardown actions (e.g., closing the browser, clearing cookies).
• StepHooks.java: This file is used to define hooks that are specific to individual test steps. It could involve verifying certain conditions before or after each step is executed in a test scenario.
• AbstractHook.java: This file contains abstract methods or reusable code that can be shared among the different hook classes. It serve as a base class for more specific hook implementations, providing common functionality such as logging or error handling.

Summary:

The hooks folder organizes the setup and teardown logic required for your tests. Hooks are essential for preparing the environment or cleaning up after tests, ensuring the tests run in isolation and with the necessary preconditions. The api folder contains hooks related to API testing, while the webdriverio folder handles hooks related to browser automation.

src/test/java/pages

The pages folder follows the Page Object Model (POM) design pattern, which is commonly used to organize the structure of web and mobile UI test automation. Here's a breakdown of the folder structure:

Subfolders:

1. demo/android: This subfolder contains page classes related to Android mobile automation for demo purposes. These classes define the structure and actions available on specific screens of an Android application.

2. linagora/tmail:

• mobile: This folder contains classes that represent mobile pages or screens within the Linagora Tmail application. These classes include elements and methods that interact with the mobile version of the Tmail app.
• web: This subfolder contains page classes for the web version of the Linagora Tmail application. Each class represents a different web page, defining the locators and methods to interact with web elements like buttons, text fields, etc.

Files:

1. CommonAndroid.java: This class contains common methods or locators that are shared across different Android screens. It include reusable actions like clicking buttons, filling text fields, or verifying elements that are consistent across multiple Android pages.

2. CommonApi.java: This class contains methods for interacting with APIs, which could be used in tests that involve making API calls in combination with UI interactions. It contain methods for sending requests, handling responses, or setting up API configurations.

3. CommonWeb.java: Similar to CommonAndroid.java, this file defines common methods and locators for interacting with web pages. It might include functions for navigation, form submissions, or element verification that are used across different web pages of the Linagora Tmail app.

Summary:

The pages folder organizes the page classes following the Page Object Model, which enhances the reusability and maintainability of UI tests. Each subfolder categorizes pages based on the platform (e.g., Android or Web) and the application (e.g., Linagora Tmail). The common classes (CommonAndroid.java, CommonApi.java, and CommonWeb.java) hold reusable methods for interacting with various platforms, ensuring consistency and reducing code duplication across your tests.

src/test/java/runners

The runners folder contains classes responsible for executing the test cases. These classes are configured to run the Cucumber features and define how the tests will be executed, often involving integration with frameworks like TestNG or JUnit. Here's a description of each file:

Files:

1. AbstractRunner.java: This is a base class that provides common functionality for other runner classes. It could contain shared configurations or setup/teardown logic that is inherited by specific runners, such as initializing test data or configuring Cucumber options. Abstract classes like this help avoid code duplication across different runner implementations.

2. TestRunner.java: This class is the main runner for executing your test scenarios. It may be configured with @CucumberOptions to define which feature files to run, what glue code (step definitions) to use, and any additional configurations (such as tags, reports, or plugins). This runner might be linked with TestNG or JUnit to allow execution from the command line or build tools like Maven.

3. TestWipRunner.java: The name "Wip" stands for "Work in Progress." This runner is used for running tests that are under development or tests that are not ready for the main execution suite. It might include configurations for running a subset of features or scenarios marked as "WIP" (Work In Progress).

Summary:

The runners folder organizes classes that are used to trigger the execution of tests. The AbstractRunner.java serves as a base class providing shared functionality, while TestRunner.java runs the primary test scenarios, and TestWipRunner.java is for executing tests still in development or marked as work in progress. These runner classes typically use Cucumber's @CucumberOptions to define how the tests are executed and integrated into the larger framework (e.g., TestNG or JUnit).

src/test/java/steps

The steps folder in your Selenium Java project contains the step definition classes for Cucumber. These classes map the Gherkin scenarios in your feature files to executable code, defining how each step should be performed during test execution. Here's a breakdown of the folder structure:

Subfolders:

1. demo: This folder contains step definition classes for demo-related test scenarios. These steps define actions for the demo feature files under the features/demo folder, mapping each Gherkin step to its corresponding code.

2. linagora/tmail:

• mobile: This subfolder contains step definition classes specific to mobile testing for the Linagora Tmail application. It includes actions and verifications that interact with the mobile version of the Tmail app.
• web: This subfolder holds step definition classes for web-based testing of the Linagora Tmail application. These classes are responsible for performing actions and checks within the web version of the application.

Files:

1. CommonAndroidSteps.java: This file contains common step definitions for Android-related scenarios. It may include steps for interacting with Android-specific elements, such as navigating through the app, clicking buttons, or verifying mobile-specific behaviors.

2. CommonApiSteps.java: This class contains step definitions for API-related scenarios. It defines steps for making API calls, validating responses, or interacting with backend services during tests.

3. CommonSteps.java: This class probably contains general or reusable step definitions that are applicable across different platforms or scenarios. These could be steps like logging in, navigating through common pages, or handling generic verification steps.

4. CommonWebSteps.java: This file contains step definitions for interacting with web pages during the test execution. It defines steps to perform browser-based actions such as filling forms, clicking buttons, or validating page content in the web version of the application.

Summary:

The steps folder contains Cucumber step definition classes that connect Gherkin scenarios to actual Selenium code execution. These step definitions enable tests to interact with the application, either through mobile (Android), web, or API layers, based on the test platform or application being tested (e.g., Linagora Tmail). Each class defines a series of actions and assertions, making the test automation framework flexible and organized.