Skip to content

Jenkins - Remote Testing

Running automated tests, especially UI or E2E tests (like Selenium, Cypress, Playwright), often requires specific environments (browsers, drivers, OS) or significant resources. Executing these tests on dedicated Jenkins agents (remote machines) is a common practice.

  1. Distributed Builds Setup: You need Jenkins agents configured and connected to the controller. See the ‘Distributed Builds (Agents)’ chapter.
  2. Agent Environment: The chosen agent(s) must have the necessary testing software installed:
    • The test execution framework/runner (e.g., Maven/Gradle for Java tests, Node.js/npm for Cypress/Playwright).
    • Web Browsers (Chrome, Firefox, etc.) if running UI tests.
    • Corresponding WebDriver executables (ChromeDriver, GeckoDriver) placed in the system PATH or specified in test code/configuration.
    • Any other dependencies required by your tests.
  3. Test Code: Your automated tests should be part of your project, typically executed via a build tool command.
  4. Pipeline Configuration: Your Jenkins Pipeline (Jenkinsfile) should be configured to run the testing stage on the appropriate agent(s).

Alternative: Instead of manually setting up agent environments, consider using Docker agents with pre-built images containing browsers and drivers (e.g., Selenium Docker images) or cloud testing platforms (Sauce Labs, BrowserStack).

The key is to use the agent directive in your Jenkinsfile to target the stage containing your tests to the correctly configured agent(s).

Example: Running Selenium Tests (via Maven) on a Labeled Agent

Section titled “Example: Running Selenium Tests (via Maven) on a Labeled Agent”

Assume you have an agent configured with the label selenium-agent which has Java, Maven, Chrome, and ChromeDriver installed.

pipeline {
agent any // Build stage might run anywhere
stages {
stage('Build') {
steps {
sh 'mvn clean package -DskipTests'
// Archive artifact if needed for deployment before test
// archiveArtifacts artifacts: 'target/*.war'
}
}
// Deployment to test environment might happen here
// stage('Deploy to Test Env') { ... }
stage('Run Selenium E2E Tests') {
// *** Target this stage to the specific agent ***
agent { label 'selenium-agent' }
steps {
echo "Running tests on agent: ${env.NODE_NAME}"
// Assuming tests run via 'mvn verify' or a specific profile
// Pass the application URL if needed
sh 'mvn verify -Pselenium-tests -Dwebapp.url=http://test-env.example.com'
}
post {
always {
// Publish results generated on the agent
junit '**/target/failsafe-reports/*.xml'
}
}
}
}
}

How the agent connects affects setup:

  • SSH Agents (Recommended for Linux/macOS): Configure the agent in Jenkins with SSH credentials. Jenkins connects to the agent. Ensure the agent has SSH server running and necessary tools installed.
  • JNLP Agents (Agent connects to Controller): Configure the agent in Jenkins with ‘Launch agent via connection to the controller’. Start the agent process on the remote machine manually (using java -jar agent.jar -jnlpUrl ... -secret ...) or via a script/service. Requires the JNLP port (e.g., 50000) to be open on the controller and accessible from the agent. This method is generally less preferred now due to setup and potential firewall complexities.
  • Windows Agents: Can be launched via SSH (if SSH server installed), JNLP, or configured to run as a Windows service.
  • Agent Connectivity: Ensure the agent is online and connected in Manage Jenkins → Nodes.
  • Environment Mismatches: Verify the exact versions of browsers, drivers, Java, Node.js, etc., on the agent match what the tests expect.
  • PATH Issues: Ensure WebDriver executables and build tools are correctly in the PATH for the user running the agent process.
  • Permissions: Check file system permissions in the agent’s workspace directory (Remote root directory).
  • Headless Mode: If the agent has no display, ensure browsers are configured to run in headless mode.
  • Firewalls: Network firewalls might block connections between the agent, controller, or the application under test.
  • Test Failures: Examine the console output and published test results (junit, HTML reports) for specific error messages from the test framework or WebDriver.

Running tests remotely on dedicated agents allows you to scale your testing efforts and ensure tests run in consistent, appropriate environments.