Transcripted Summary
One of the most important pieces of using the Selenium side runner, aside from the ability to have your test run cross-browser and in parallel, is the ability for you to wire up your tests from Selenium IDE to a CI server.
CI is short for continuous integration. So, if you're not familiar with the concept, and what a CI server is, I'm just going to briefly cover that, and talk about some general ideas about how CI can be used within a software development practice and then where it fits within test automation for end to end testing.
What CI server do you use?
That's a great question. There's a link at the bottom of this lesson that kind of recaps what a CI server is and a list of most of the CI servers that are available today.
So, a CI server or continuous integration in general, is a software development practice where members of a team integrate their work frequently. The idea is that you want to avoid what's called “integration hell” — where you want to have each person ideally integrate their code changes at least once a day and then this leads to multiple integrations per day.
It's a very common practice that came out of eXtreme Programming (XP).
Then each integration is ideally verified by an automated build, which includes tests of some kind, generally unit test, potentially integration tests.
Then we, in test automation, we want to co-opt this practice for end-to-end test automation as well.
So, the idea is to use a CI server to automate building, code changes, as well as executing automated tests, to verify correctness, and make sure things work appropriately.
There's a few different ways to structure this. Travis CI has a great breakdown of a couple different workflows that they built there service around, the concept of.
One option is the branch build flow.
So, it's heavily reliant on being in a service provider like GitHub, so you push your code to version control system, then that triggers a job to be run in CI, in Travis.
Then if your build passes, then a deployment happens and then from there you get notifications. So, in this case with Slack.
There's also doing it based on a _pull request. _
So, a specific piece of code that was built and then submitted for review. You request a pull request and then GitHub fires a hook to Travis to run then tests.
And then assuming the build passes, then Travis updates the status, then you can merge the PR.
So, something along these lines can be used for test automation in addition to these workflows.
You could use a Cron job — e.g., schedule your tests surrounding a certain time. Some people view that as an anti-pattern and some people view that as a necessary practice. It may vary from your team to team.
There's also the option to just do something akin to what Travis has set up, but in a more general way. Perhaps a build happens on CI, a bunch of changes were pushed, a build happens, and then it triggers a deployment to an environment. This environment is ready, and it is testable from an end-to-end perspective, and then a job can then run for the Selenium IDE tests.
You might already have something like this within your organization. Also, you can just potentially create it yourself.
So, it really depends on what you already have set up in terms of continuous integration within your team or teams, and it you're starting from scratch, then you kind of have a lot of options to choose from. So really, it's just a matter of working within the confines of what already exists within your organization and working with your team to define the best fit of where your automated tests with Selenium IDE fit into this practice.
So, there's a bunch of different options out there. Just a few to name, Bamboo from Atlassian, CircleCI, Jenkins, TeamCity, and Travis, and the list goes on.
I want to just step through a really quick demo just to show you how straightforward it can be logistically just to hook up the Selenium SIDE runner test execution into a job in Jenkins.
So, if we hop over to Jenkins, we see the home page and we have no jobs for Jenkins. This is just the home page of an instance I have running locally on my machine. For you to do this in practice, you would likely have it hosted elsewhere, but just for argument’s sake, this is meant to just demonstrate the logistics of wiring this up.
We'll go ahead and we'll do two things. We'll create a new job and also do a quick bit of configuration.
Rather than having to specify the environment variable for using Applitools directly in the job, we can specify that within a setting within Jenkins itself. So, you have one or two options to do it, but if you had a bunch of environment variables you needed, if you're using other third-party services, you can come in and “Configure System” and actually specify environment variables globally for all of Jenkins. So, it cleans up things a bit. Then if you had to have multiple jobs using the Selenium SIDE runner, you wouldn't have to continually use the same environment variable. You can just specify it in one place.
So, we'll go ahead and do that here with the Applitools API key and paste in.
Then we'll go ahead and click save, and that takes us back to the home page.
Now here we can create a new job. This will just be our log in test, however you name your jobs in CI is up to you. Generally, I've seen people name it based on the thing that's being tested, potentially including the browser and OS combination that's being used in that job because generally you could separate builds most likely out into — these tests run on IE and these tests run on Chrome. As opposed to — these tests just test this piece of functionality and run on all the browsers.
Right now, we're just set up to only run on one browser OS combination at a time with the runner. So that's generally how people might set it up.
So, for ease of naming, I'll just call this one “Login”. We'll select the only option, which is “Freestyle project”, and then click OK.
This takes us into the configuration management within the job and there's a bunch of different things you can do here.
Ideally, we're storing your Selenium IDE project file in source control, you'd come and configure this here to make options appear for Source Code Management. There's a plugin within Jenkins you can install for Git, for Subversion and the list goes on,
And then Build Triggers.
This is really where things get interesting where you can configure the job to meet the context of your team, to figure out how it fits into the overall development life cycle of what your teams are doing. Or it could just live here and potentially this job could be called as a matter of some other job that completes. So, a lot of variations exist in terms of how you could configure this,
But the part we're going to pay attention to is predominantly the Build step.
We want to come into the Build section and click on “Add build step”, and we want to “Execute shell”.
Then from here, we don't have to specify the environment variable anymore for Applitools. We can just do selenium-side-runner and for just this example, I'm going to show plugging this in using headless testing just for simplicity.
So, we will use the capabilities of browserName=chrome, and then chromeOptions.args=[headless] and then the path to where the project file is. In this case it's on my local machine. It's not in version control. So there doesn't have to be a relative path, it just has to be a path that's absolute for this machine, and it is in my Downloads directory.
selenium-side-runner -c “browserName=chrome chromeOptions.args=[headless]" =/Downloads/the-internet.side
So that should be everything. We'll go ahead and we can click save.
Then we can actually build this. Just to show you that it wired up and worked. So, everything's running. It's running headlessly. There's nothing else running.
Then you can come in and actually click on the console output as the job is running and see everything. Then once the job is complete, that information persists here along with the resulting output whether or not the test passed or failed.
That's it, the test ran and passed through CI, and if we had wired this up so it would be triggered based on some predefined action elsewhere in the build pipeline, then this would have triggered and run. Then the only thing that's missing is the ability to send notifications.
If you were setting up Jenkins and if you wanted to configure Git integration and other plugin integrations, then just real briefly I'll show you.
You'd come into “Manage Jenkins” and you can come into “Manage Plugins”.
Then from here, click on the “Available” tab and you can search to find the plugins that you want. So, say you use Slack and you want to do a Slack integration, then you can use the Slack notifier. And if you wanted Git, then you'd search for Git and the list goes on. Then you can install it and then there's links to documentation to configure it.
So that's CI in a nutshell.
That's a really simplistic overview of how to wire it up, but again, it's worth figuring out what the context is within your organization, your team or set of teams. Figure out what the common practice is, what the development pipeline is already, and how to fit your automated testing into that.
