Continuous Integration is considered to be one of the best practices in development where code integrations are done frequently into the code repository rather than waiting to commit a larger version of it. As a part of continuous integration, the developer should make sure that integrations being done should not break the code which is already available as being a shared repository it would be having a significant impact.
In order to overcome the above problem, Travis CI would help the user in reporting automatic build changes and testing the integrations, deployment management and also it fails proofs your code repository with improved and shippable software quality with reduced risks, better collaboration.
In the below article, I will walk you through the Travis CI overview, advantages of using Travis CI, how to configure Travis CI with your current test automation repository to enhance your CI CD pipeline with the execution of tests over LambdaTest cloud to achieve your cross browser testing goals. You would gain insights on how to test locally hosted web pages on Travis CI and how to configure you parallel tests with the help of Selenium Training Grid in our configuration part of the article.
Introduction to Travis CI
Travis CI is cloud-based CI service which builds and tests your projects hosted on GitHub. For every commit made Travis CI would trigger a build process to validate the build and would report any failures. It fetches the commands from a .travis.yml file which is a YAML based file format from the root folder of your project to get started with the build process. Travis YML file would enable the Travis CI to understand which programming languages are being used, branch specifications required for the build to be triggered, installation of dependencies if there are any required.
Every other code repositories have their own Continuous Integration tools nowadays, let’s take Bitbucket being an Atlassian code repo, Bamboo is a tool which comes along. If you prefer GitLab as your code repo, GitLab CI exists. Tool selection could also be majorly impacted due to the code repository being used for version controlling. Currently, we have myriad of tools available which are both free and open source. Some of the major used tools are listed below. Dependencies rely on the development environment being used and also the code repositories which are being used for version controlling purposes.
In the case of Travis CI below is some of the prerequisites to get started.
- A mandatory GitHub account
- Permission for integrating GitHub code repo with the Travis CI.
Why Travis CI?
- It seamlessly integrates with GitHub and easy to set up, everything user needs to do is to Sign Up with GitHub and authorize to sync their GitHub projects which we would have a detailed walkthrough in the upcoming configuration section of the article.
- Extensive documentation is available to get started where you can head over to https://docs.travis-ci.com/ for reference. Where sections related to installing dependencies, configuration options in different programming languages along with encryption and integration topics discussed in detail.
- Support almost every other programming language and cloud solutions for deployments.
- Travis CI would seamlessly integrate with cross-browser testing solutions such as LambdaTest for parallel testing.
- Travis CI is not platform dependent as it supports multiple platforms apart from Windows such as Mac and Linux. Infrastructure dependencies might vary depending upon the environment being used. However, you can navigate through the detailed documentation available.
- Travis CI is free for open sourced projects i.e. projects which are public over GitHub, for private repositories, there is an enterprise version available.
- Automatic build triggers when there is a change in code repository with user desired configuration where the user can select the branch name which is specified in the Travis yml file in the root folder of your project.
Problems with Travis CI
- Integrates only with GitHub. Travis CI wouldn’t any other cloud repository apart from GitHub where you might have to migrate your existing cloud repository to GitHub if it is otherwise while you plan on using Travis CI.
- Private repo comes in an Enterprise Version where you have to pay after trial version which involves first 100 builds for free.
Configuring Travis CI First Instance
Let’s get started with the Configuration of Travis CI.
Login to your GitHub account with a valid username and password. Select the repo your planning on integrating it with Travis CI. Make sure your repo is up to date.
Step 1: Log on to https://travis-ci.com/ and sign up with your GitHub account used above.
Step 2: Provide authorization as requested, reference provided in the below image.
Step 3: Once you have completed the sign-up and authorization process you would be redirected to the dashboard where towards the left-hand corner of your screen you would be prompted for a sync account option. This would ideally sync all your existing GitHub projects with your Travis CI.
Step 4: Under Legacy Service Integrations you can view all your current repositories synced on to your Travis CI.
By default, the CI process for all repositories would be turned off, click on the turned off button to turn on the integration for a specific project.
Step 5: Now you need to add a .travis.yml file to root folder of your current automated test suite.
What is a .travis.yml file?
Travis YML is a configuration file placed in the root folder of your project used to defined how to configure the build-related information.
If a .travis.yml is not in your repository or is not valid YAML, Travis CI will ignore it.
You can find all language related templates, please head over to http://docs.travis-ci.com/user/language-specific/. The file consists of information such as what programming language is being used, what operating system is being used, branch name of th repo which is being targeted.
Once the .travis.yml file in created and pushed to GitHub repo, upcoming commits to the repo would trigger a build in Travis CI cloud which would be similar to that of in below image. After a successful integration with the help of configuration file Travis CI has a certain mechanism which compiles the GitHub code whilst it would pull in the code for the first time and then on each commit to the repo or the specific branch could trigger a compilation process. Provided below are the screens of Travis CI.
Active Repositories View:
JobView after build completion:
Job Log Sample:
View Config consists of the configuration information as shown in the image below.
Step 6: Fork https://github.com/bharadwaj-pendyala/Cucumber-and-TestNG-Template repo and now sync your forked repo with Travis CI through the above process.
Or if you don’t want to fork the above-mentioned repo, make sure you select a repository of you to choose which is not empty in your GitHub account enabled with build tool configuration such as Maven or ant which would be helpful in the compilation process.
Step 7: Enable the synced repository, once you enable it this synced repo should be visible in my repositories page.
Step 8: Add .travis.yml file to the repo with below build configuration for compilation.
language: java
sudo: false
script: “mvn test”
Make sure that you enable your framework in such a way that tests get triggered through the maven command – “mvn test” as specified in the configuration file.
Step 9: Once the above configuration file is committed and pushed to the main branch in GitHub. You would observe a test getting triggered with build and worker information in the job log view. This process would essentially trigger your first compilation by pulling in code from GitHub account onto the VM created by Travis CI.
As we have configured our tests to run on the LambdaTest Platform through RemoteWebDriver class, once a new commit is made, it triggers execution of the specified test suite onto the LambdaTest Platform. This would ideally identify if any user made commit is breaking the build or the automated test suite.
Integrating Travis CI with LambdaTest
LambdaTest is a cloud based cross browser testing solution which would enable us to perform automated and live interactive cross browser testing on more than 2000 browsers and operating systems online. This would help you scale up and down without much of a hassle in terms of resource allocation and deallocation, would also help you support budget estimations on resources used for parallel and cross browser testing.
Testing Local or Privately Hosted Projects
Globally enterprises use private servers for their IT purposes for enabling better web protection and security, LambdaTest would seamlessly integrate with such platforms with the help of a secure shell tunneling feature called LambdaTest Tunnel, this would also enable you to test locally hosted web pages. Let’s discuss how to configure LambdaTest Tunnel.
Step 1: Navigate to Automation Dashboard as shown in below image after logging in to your LambdaTest platform.
Step 2: Once you make a click on configure tunnel feature you would be prompted with an overlay with two sections being internal server configurations and also locally hosted web page testing features.
Step 3: Copy the access token related to the desired feature of an application under test. Please refer to below token for reference.
LT -user [email protected] -key qYlLn1IzVrC2U41zM4kyjv35EvpHxR2tyMB4aEBlkNMmvpnQ5A
We would be making use of this token while configuring our desired capabilities in our next section of the article below to demonstrate Parallel Testing with LambdaTest.
Parallel Testing With LambdaTest Selenium Grid
We would be making use of our Cucumber TestNG code repository present at https://github.com/bharadwaj-pendyala/Cucumber-and-TestNG-Template for reference. Clone the code and then import the code into the desired IDE.
We would be declaring our LambdaTest user name and password as global environment variables in the yml file in below format to be considered for execution.
env:
global:
| – LT_USERNAME=${LAMBDATEST_USERNAME} | |
| – LT_ACCESS_KEY=${LAMBDATEST_KEY} |
Where the global variable for lambda test user name would be LT_USERNAME and lambda test password would be LT_ACCESS_KEY.
Your .travis.yml code would something similar to as below.
language: java
sudo: false
script: “mvn test”
env:
global:
– LT_USERNAME=${LAMBDATEST_USERNAME}
– LT_ACCESS_KEY=${LAMBDATEST_KEY}
You can make use of this variable in while trying to trigger a remote web driver execution as shown in below code in case of our Cucumber+TestNG code.
package com.cucumber.tests;
import java.net.MalformedURLException;
import java.net.URL;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.testng.annotations.AfterClass;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
import cucumber.api.CucumberOptions;
import cucumber.api.testng.CucumberFeatureWrapper;
import cucumber.api.testng.PickleEventWrapper;
import cucumber.api.testng.TestNGCucumberRunner;
@CucumberOptions(features = { “src/test/java/features” }, glue = { “com.cucumber.stepdefs” }, plugin = { “pretty”,
“json:target/cucumber/cucumber.json” })
public class TestNGRunCucumberTest {
DesiredCapabilities capabilities = new DesiredCapabilities();
/*
* Previous declarations for LambdaTest Connect
* String username = ” bharadwajpendyala”;
* String accesskey = ” qYlLn1IzVrC2U41zM4kyjv35EvpHxR2tyMB4aEBlkNMmvpnQ5A”;
*/
protected static RemoteWebDriver driver = null;
String gridURL = “@hub.lambdatest.com/wd/hub”;
boolean status = false;
protected String baseURL = “https://www.google.com”;
private TestNGCucumberRunner testNGCucumberRunner;
@BeforeClass
@Parameters(value = { “browser”, “version” })
public void beforeClass(String browser, float version) {
capabilities.setCapability(“build”, “Cucumber_Project_Google”);
capabilities.setCapability(“name”, “Querying in google engine”);
capabilities.setCapability(“platform”, “Windows 10”);
capabilities.setCapability(“browserName”, browser);
capabilities.setCapability(“version”, version);
try {
driver = new RemoteWebDriver(new URL(“https://” + LT_USERNAME + “:” + LT_ACCESS_KEY + gridURL),
capabilities);
} catch (MalformedURLException e) {
System.out.println(“Invalid grid URL”);
} catch (Exception e) {
System.out.println(e.getMessage());
}
testNGCucumberRunner = new TestNGCucumberRunner(this.getClass());
}
@Test(groups = “cucumber scenarios”, description = “Runs Cucumber Scenarios”, dataProvider = “scenarios”)
public void scenario(PickleEventWrapper pickleEvent, CucumberFeatureWrapper cucumberFeature) throws Throwable {
testNGCucumberRunner.runScenario(pickleEvent.getPickleEvent());
}
/**
* @return returns two dimensional array of {@link CucumberFeatureWrapper}
* objects.
*/
@DataProvider
public Object[][] scenarios() {
return testNGCucumberRunner.provideScenarios();
}
@AfterClass
public void tearDown() {
driver.quit();
testNGCucumberRunner.finish();
}
}
Once you replace the TestNG Runner file with above code designation for integration of LambdaTest based parallel execution with help of Travis CI, this would help you to get the test execution trigger in LambdaTest platform as shown in the image below.
Conclusion:
We have discussed the importance of continuous integration, how it can be leveraged using Travis CI. The need for parallel and cross-browser testing using cloud solution such as LambdaTest and its needs in Continuous Integration pipeline. Advantages and Disadvantages of using Travis CI. The configuration of Travis CI with one of our framework using Cucumber and TestNG for triggering tests on LambdaTest to achieve our cross-browser testing goals. To kick start a deployment, you would need a quality check in place to validate the build. You cannot depend on manual test process in order to test each and every build integration into the environment as it is not automated and requires human dependency which proves to be tiresome and has a high chance of failure. To avoid manual quality checks for providing a sign off to the build, we make sure that we have an automated test suite which acts as a checkpoint in the Continuous Integrations through Continuous Deployment processes with the help of Travis CI. Thanks for reading the article, you have a great day and Happy Testing!
