This lesson is for PRO members.

Unlock this lesson NOW!
Already subscribed? sign in

e2e Testing AngularJS Apps with Protractor and SauceLabs

6:48 Angular 1.x lesson by

When you are running end-to-end (e2e) tests against your AngularJS apps, they will need to be run against a rainbow of varied browsers. This can be a logistics nightmare, but luckily there are services like SauceLabs that can make this much more manageable. In this lesson, we will take a look at configuring and running e2e tests with SauceLabs.

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

When you are running end-to-end (e2e) tests against your AngularJS apps, they will need to be run against a rainbow of varied browsers. This can be a logistics nightmare, but luckily there are services like SauceLabs that can make this much more manageable. In this lesson, we will take a look at configuring and running e2e tests with SauceLabs.

Avatar
Cameron

Appium version 1.2 show in the tutorial does not work, need to update it to 1.2.1.

https://github.com/angular/protractor/issues/853#issuecomment-54057350

exports.ios = {
name: 'iOS 7 - iPad',
platformName: 'iOS',
platformVersion: '7.1',
deviceName: 'iPad Simulator',
browserName: 'safari',
orientation: 'landscape',
'appium-version': '1.2.1',
tags: ['ios']
}

Now that we can run our tests against a few different browser combinations by using various arguments to our configuration script, we're going to take a look at how we actually run those tests on a hosted service like Sauce Labs. We could add that to our configuration here, but just for the sake of simplicity in showing this stuff, I'm going to use a separate configuration file.

Here we just have our basic configuration again with the path to the specs and the base URL configured, and then what we're going to do is add a couple of properties that are helpful when you're using a service, because things tend to take a little bit longer in the service, because basically the service is going to boot up a fresh VM for each test run, so things can be a little bit slower, so it's a good idea to add these things just to get as much helpful output as you can and to give it enough time.

The next thing we're going to do is add a couple of properties here. You'll notice here we're actually going to override the baseURL that we had used above and point to a public location. Generally when you're using a service to test, you're going to need to have your app publicly available so that it can reach it. There are ways to do private access, and we'll look at that in a little while, but public is the easiest way.

The next properties here are sauceUser and sauceKey, so we're going to add these to the config object directly because Protractor has direct built-in support for this. What we're doing here is we're going to tell it to use environment variable if they're available. If not, we'll just pull these values, in this case, from a creds file, where I have my information so that I don't have to have it on screen here.

The idea is that in something like your continuous integration environment, you would have these environment variables set up and be able to pull them from there.

The last step in actually being able to run these against Sauce Labs is to go add a new npm script that we call to actually use this configuration file that we worked on. If we do that and then switch to the terminal, and call "npm run test-e2e-sauce", you'll see that it tells us it is using the selenium server from Sauce Labs and we get the same output like normal.

We get that output in our terminal and see that our test did pass. In this case, we had just configured it to one browser, so that's all that ran, but you can see here it also gives us the URL to the job that it just ran for us, so if we go check that out, we can actually see the details. We can see that it passed. We can see the browser it ran on. We can see it actually ran on a Linux.

Then we can actually see the various steps that the test goes through, so we can see the app in various states, and you'll notice there's also a screencast link here above the screenshots, and we can actually click on that and see the test in progress. This can be super helpful for when things are going wrong, to actually be able to go in and see a video of the test being run, and see where things potentially went off track.

Now that we've proven that our configuration for running on Sauce Labs actually works, it's probably a good idea to go back and add some additional browsers, because that's a real benefit of using a service like Sauce, that you can run on various browsers and not have to have them installed on your system, so things like old versions of IE are very easy to test against.

If we actually just look at this browser's file here that we're referencing, you can see we just have a handful of different browsers configured. We've got, of course, Chrome and Firefox, we've got various versions of IE from 8 all the way up to 11, and then finally we have our mobile Safari iPad browser configured again.

If we then go add those to our multiCapabilities array here, and save that file, and then go re-run our "npm run test-e2e-sauce", you can see that we're going to be running six instances of WebDriver this time for all the different browsers we have. This is going to take a little while to run, so if you're running this outside of a continuous integration environment, you will need a little bit of patience.

Just to show you a couple more of the features of Sauce Labs, if we actually go to the site, and go where we've got all of our different tests listed out, we can filter this down to just tests that have run today, because I've got quite a lot of history in here, but you can then see all the tests that have been run.

You can notice this tags column. I tend to tag things by groups that I might want to review later, like all the IE tests, or all the iOS tests, and things like that. Then we can also actually view one of these tests in progress, so we can essentially get a live video feed of the VM running the test on whatever the configured browser is. In this case it's IE, and we can see that test running.

Again, it's not super high fidelity or super fast, but it is sometimes useful to go in and see those things.

We can see here that several of our tests have finished running. We're down to one instance still running at this time, and now everything is finished, and we can see that everything passed, so we're good.

We have just tested our application against six different browsers, at least three of which would've not been easily configurable on our own system, and essentially all we had to do to get that to work was to add these sauceUser and sauceKey properties, and then a couple of these configuration options, which are helpful but not necessarily required, and essentially that's it. Other than that, we've not had to modify our tests at all.

The last thing I did want to show real quick was I mentioned that you can run tests that are not publicly available if you need to, and the way that you do that is if we actually just comment out this baseURL override that we have, and then if you use the desktop app that Sauce provides, called Sauce Connect, you can then go and tell it to start Sauce Connect, which will essentially establish a tunnel to your local network, and then you can access things on URLs like local host or that may be on some other internal network.

That's basically it.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?