So last year I shared my initial experiences of getting started with Protractor. Here are some things i’ve learnt since then.
As your Protractor tests grow you are undoubtably going to make use of testSuites. This allows a specific group of tests to be run by passing in the testSuite name into the run parameters.
Protractor uses a configuration file which contains various settings for your tests such as baseUrl, tests to run, web driver port etc. When running tests in different places it is tempting to have multiple configuration files. For example a local config and one for your CI server. Avoid this temptation and only have one config file.
Keeping Protractor up-to-date as well as other packages, such Screenshot Reporter, which you depend upon is really important. If you don’t manage your packages they will quickly become out of date. Luckily using a package.json to store all your packages makes this super easy. You can declare if you want to auto update or use a specific package version when you run npm install.
Protractor can be used to test non-AngularJS sites but i’d only recommend this when testing a user-flow which jumps out of your AngularJS site, for example page redirects. I would suggest not using this capability to mean you can test non-Angular sites using Protractor.
The joy of using Node is that Node Package Manager allows you to do loads of stuff. An example is http-request which you can use to call API’s in your test flow. This is particularly useful if you want to setup some data via a direct API call.
Just do it.
In Protractor it’s so easy to run your tests in parallel and across multiple browsers. Even with a handful of tests you are going to have to look at running tests in parallel for time saving benefits. Running tests in parallel also forces you to have independent tests which is a good way to keep tests maintainable.
Protractor by design does not open/close the browser between specs. This is useful in one way because it speeds up your tests. Closing and Opening browsers between tests has a significant footprint. There are cases though when you need to potentially close a browser to at least clear cookie or session history. In this case you have a couple of options. Firstly WebDriver can interact with cookies or alternatively you can add restartBrowserBetweenTests: true to your protractor config file.
11. Learn AngularJS
Having an understanding of the underlying technology is a huge help in writing good tests. As you’ll probably be using Protractor to tests AngularJS sites then you should definitely learn Angular. Build your own site in Angular and write some tests for it. There are tonnes of great sessions on Pluralsight to help. Learn also how to unit test AngularJS code as this will give you a better appreciation of where to place your test efforts.
At AngularConnect Uri Shaked did a great talk on how to use ES6 generators to control the flow of your Protractor Tests. This is particularly useful if you need certain tasks to occur in a particular sequence.
Protractor is a wrapper around WebDriver specifically designed for AngularJS apps. This means most of the benefit will come when using AngularJS apps. The two primary benefits i’ve found are:
- Page synchronisation – As protractor hooks into the angular digest cycle it makes one of the typical problems with E2E tests, When has the page loaded?, problems a lot easier to manage.
- Angular Specific Locators – by.Binding, by.Model, by.Repater gives you more options for finding stuff on a page.
With this in mind i wouldn’t ever consider using Protractor for a site which isn’t built in AngularJS.
Thats more than enough tips for now.