GitHub Actions configuration in Selenium Java - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

GitHub Actions: Workflow Run Result

Given this GitHub Actions workflow snippet, what will be the output of the Run tests step if the Java Selenium tests pass?

Selenium Java

name: Java Selenium Tests

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: '17'
      - name: Run tests
        run: ./gradlew test

A Error: Gradle not found

B BUILD FAILED\n1 test failed

C BUILD SUCCESSFUL in 10s\n5 tests completed, 0 failed

D Permission denied: ./gradlew

💡 Hint

Think about what happens when tests pass in a Gradle build.

If the Selenium Java tests pass, Gradle reports BUILD SUCCESSFUL and shows the number of tests completed with zero failures.

❓ Configuration

intermediate

Correct GitHub Actions Step to Cache Gradle Dependencies

Which step configuration correctly caches Gradle dependencies in a GitHub Actions workflow?

A

  - name: Cache Gradle
    uses: actions/cache@v3
    with:
      path: ~/.m2/repository
      key: ${{ runner.os }}-maven-${{ hashFiles('**/*.pom') }}

B

  - name: Cache Gradle
    uses: actions/cache@v3
    with:
      path: ~/.gradle/caches
      key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle') }}
      restore-keys: |
        ${{ runner.os }}-gradle-

C

  - name: Cache Gradle
    uses: actions/cache@v2
    with:
      path: ~/.gradle/wrapper
      key: ${{ runner.os }}-gradle-wrapper

D

  - name: Cache Gradle
    uses: actions/cache@v3
    with:
      path: ~/.gradle
      key: ${{ runner.os }}-gradle-cache

💡 Hint

Gradle caches are usually stored in ~/.gradle/caches.

Option B caches the Gradle caches directory and uses a key based on OS and Gradle files hash, which is the recommended approach.

❓ Troubleshoot

advanced

Diagnosing GitHub Actions Selenium Test Failure

A GitHub Actions workflow running Selenium Java tests on ubuntu-latest fails with the error java.lang.IllegalStateException: The path to the driver executable must be set by the webdriver.chrome.driver system property. What is the most likely cause?

A The ChromeDriver executable is not installed or not found in the PATH on the runner.

B The Java version is incompatible with Selenium WebDriver.

C The workflow is missing the checkout step to get the source code.

D The Gradle cache is corrupted causing driver download failure.

💡 Hint

Think about what Selenium needs to control the browser.

Selenium requires the ChromeDriver executable to be available and its path set. If missing, this error occurs.

🔀 Workflow

advanced

GitHub Actions Workflow for Parallel Selenium Tests

Which workflow configuration correctly runs Selenium Java tests in parallel on 3 different Java versions (11, 17, 20)?

A

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        java-version: [11, 17, 20]
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK
        uses: actions/setup-java@v3
        with:
          java-version: ${{ matrix.java-version }}
      - name: Run tests
        run: ./gradlew test

B

jobs:
  test11:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: 11
      - run: ./gradlew test
  test17:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: 17
      - run: ./gradlew test
  test20:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 20
        uses: actions/setup-java@v3
        with:
          java-version: 20
      - run: ./gradlew test

C

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK
        uses: actions/setup-java@v3
        with:
          java-version: '11 17 20'
      - name: Run tests
        run: ./gradlew test

D

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        java-version: [11, 17, 20]
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK
        uses: actions/setup-java@v3
        with:
          java-version: 11
      - name: Run tests
        run: ./gradlew test

💡 Hint

Look for matrix strategy usage for parallel jobs.

Option A uses a matrix strategy to run the same job with different Java versions in parallel, which is the correct approach.

✅ Best Practice

expert

Best Practice for Secure Secrets in GitHub Actions

Which practice is the best way to securely use browser driver credentials or API keys in a GitHub Actions workflow for Selenium Java tests?

A Hardcode the credentials directly in the workflow YAML file for easy access.

B Send credentials as plain text in workflow logs for debugging purposes.

C Commit the credentials in a separate config file in the repository and read it during the workflow.

D Store secrets in GitHub repository secrets and access them via <code>${{ secrets.SECRET_NAME }}</code> in the workflow.

💡 Hint

Think about how to keep sensitive data safe in public or shared repos.

GitHub Secrets provide encrypted storage for sensitive data and are the recommended way to use credentials securely in workflows.

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