GitHub Actions configuration in Selenium Java - Framework Patterns

Framework Mode - GitHub Actions configuration

Folder Structure

selenium-java-project/
├── src/
│   └── test/
│       └── java/
│           └── com/
│               └── example/
│                   ├── pages/
│                   │   └── LoginPage.java
│                   ├── tests/
│                   │   └── LoginTest.java
│                   └── utils/
│                       └── WebDriverFactory.java
├── testng.xml
├── pom.xml
├── .github/
│   └── workflows/
│       └── selenium-tests.yml
└── README.md

Test Framework Layers

• Driver Layer: WebDriverFactory.java manages browser driver setup and teardown.
• Page Objects: Classes in pages/ represent UI pages with locators and actions (e.g., LoginPage.java).
• Test Layer: Test classes in tests/ contain test methods using TestNG annotations.
• Utilities: Helper classes for common functions like waits, logging, or config reading.
• Configuration: testng.xml defines test suites and groups.
• CI/CD Integration: GitHub Actions workflow file triggers tests on code push or pull requests.

Configuration Patterns

• Environment Variables: Use GitHub Actions secrets for sensitive data like credentials.
• Browser Selection: Parameterize browser choice in WebDriverFactory using system properties or environment variables.
• TestNG XML: Define test suites and parallel execution settings.
• GitHub Actions Workflow: Use matrix strategy to run tests on multiple browsers or Java versions.

name: Selenium Java Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        browser: [chrome, firefox]
        java-version: [17]
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK
        uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: ${{ matrix.java-version }}
      - name: Cache Maven packages
        uses: actions/cache@v3
        with:
          path: ~/.m2/repository
          key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
          restore-keys: |
            ${{ runner.os }}-maven-
      - name: Run tests
        env:
          BROWSER: ${{ matrix.browser }}
          USERNAME: ${{ secrets.TEST_USERNAME }}
          PASSWORD: ${{ secrets.TEST_PASSWORD }}
        run: mvn clean test -Dbrowser=${{ matrix.browser }}

Test Reporting and CI/CD Integration

• Use TestNG default reports and configure Maven Surefire plugin to generate XML reports.
• Integrate Allure or ExtentReports for rich HTML reports (optional).
• GitHub Actions uploads test results as artifacts or uses annotations to show failures inline.
• Fail the workflow if tests fail to prevent merging broken code.
• Schedule nightly runs or run on pull requests to ensure continuous quality.

Best Practices

• Keep tests isolated and independent to run in any order.
• Use explicit waits in page objects to handle dynamic elements.
• Store sensitive data like credentials in GitHub Secrets, never in code.
• Use matrix strategy in GitHub Actions to test multiple browsers and Java versions.
• Keep workflow files simple and readable; document steps clearly.

Self Check

Where in this folder structure would you add a new page object class for a "Dashboard" page?

Key Result

Organize Selenium Java tests with clear layers and use GitHub Actions matrix to run cross-browser tests automatically.

Practice

1. What is the main purpose of a GitHub Actions workflow file in a Selenium Java project?

easy

A. To store test results permanently on GitHub

B. To write Java code for Selenium tests

C. To automate running Selenium Java tests on code changes

D. To manually trigger tests from the command line

Solution

1. Step 1: Understand the role of GitHub Actions workflow

   The workflow file defines automated steps that run on events like code changes.

2. Step 2: Connect workflow to Selenium Java tests

   It automates running Selenium Java tests whenever code is pushed or a pull request is made.

3. Final Answer:

   To automate running Selenium Java tests on code changes -> Option C

4. Quick Check:

   Workflow automates tests = D [OK]

Hint: Workflows automate tasks on code events like push or PR [OK]

Common Mistakes:

• Confusing workflow with writing test code
• Thinking tests run only manually
• Assuming workflow stores test results

2. Which of the following is the correct syntax to specify the Java version in a GitHub Actions workflow step?

easy

A. java-version: 17

B. uses: actions/setup-java@v3
with:
java-version: '17'

C. run: setup-java --version 17

D. setup-java version=17

Solution

1. Step 1: Identify correct action usage syntax

   The official way to set Java version is using 'uses' with 'actions/setup-java@v3' and 'with' parameters.

2. Step 2: Check the correct parameter name and format

   The parameter is 'java-version' with the version as a string, e.g., '17'.

3. Final Answer:

   uses: actions/setup-java@v3 with: java-version: '17' -> Option B

4. Quick Check:

   Correct action syntax = C [OK]

Hint: Use 'uses' with 'actions/setup-java@v3' and 'java-version' key [OK]

Common Mistakes:

• Using 'run' instead of 'uses' for setup-java
• Missing 'with' keyword
• Incorrect parameter name or format

3. Given this GitHub Actions snippet, what will happen when code is pushed to the main branch?

on:
  push:
    branches:
      - main
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-java@v3
        with:
          java-version: '11'
      - run: mvn test

medium

A. The workflow runs tests using Java 11 on push to main branch

B. The workflow runs tests using Java 17 on any branch push

C. The workflow does not run because 'on' is missing

D. The workflow runs but skips tests

Solution

1. Step 1: Analyze the trigger event

   The workflow triggers on push events to the 'main' branch only.

2. Step 2: Check Java version and test command

   Java 11 is set up, and 'mvn test' runs the tests.

3. Final Answer:

   The workflow runs tests using Java 11 on push to main branch -> Option A

4. Quick Check:

   Push to main triggers tests with Java 11 = B [OK]

Hint: Check 'on' event and Java version in 'setup-java' step [OK]

Common Mistakes:

• Assuming tests run on all branches
• Confusing Java 11 with Java 17
• Ignoring the trigger event

4. Identify the error in this GitHub Actions workflow snippet for running Selenium Java tests:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-java@v3
        with:
          java-version: 11
      - run: mvn clean test

medium

A. java-version should be a string, e.g., '11'

B. Missing 'on' trigger event

C. The 'run' command should be 'mvn test clean'

D. actions/checkout@v3 is deprecated

Solution

1. Step 1: Check the 'java-version' format

   The 'java-version' parameter must be a string, so it should be '11' with quotes.

2. Step 2: Verify other parts

   Though 'on' is missing, the question focuses on the snippet error; 'mvn clean test' is correct; 'actions/checkout@v3' is current.

3. Final Answer:

   java-version should be a string, e.g., '11' -> Option A

4. Quick Check:

   Java version needs quotes = A [OK]

Hint: Always quote Java version in setup-java 'with' block [OK]

Common Mistakes:

• Using number instead of string for java-version
• Confusing order of mvn commands
• Assuming checkout action is outdated

5. You want to run Selenium Java tests on both push and pull request events, but only for the 'develop' and 'release' branches. Which is the correct 'on' configuration in your GitHub Actions workflow?

hard

A. on:
push:
branches: [develop]
pull_request:
branches: [release]

B. on:
push:
branches: [main]
pull_request:
branches: [main]

C. on:
push:
branches-ignore: [develop, release]
pull_request:
branches-ignore: [develop, release]

D. on:
push:
branches: [develop, release]
pull_request:
branches: [develop, release]

Solution

1. Step 1: Understand event triggers for push and pull_request

   You want both push and pull_request events to trigger on 'develop' and 'release' branches.

2. Step 2: Check correct syntax for multiple branches

   Use 'branches' with a list of branch names under both push and pull_request keys.

3. Final Answer:

   on: push: branches: [develop, release] pull_request: branches: [develop, release] -> Option D

4. Quick Check:

   Push and PR on develop, release branches = A [OK]

Hint: List branches under both push and pull_request keys [OK]

Common Mistakes:

• Using branches-ignore instead of branches
• Triggering on wrong branches like main
• Separating branches for push and pull_request incorrectly