An Intro to Automated Testing with Protractor

This is not a step by step tutorial on how to write your first automated test (look out for that post soon!), rather this is an explanation to what Protractor and end-to-end tests are.

Protractor is an end-to-end test runner that simulates user interactions to help capture any bugs once a new feature is integrated into an AngularJS application. While Protractor is specific to AngularJS applications, if you have a non-Angular app there are ways to make it work.

End-to-end tests, or e2e tests as the cool kids like to say, are simply tests that check whether the flow of an application is performing as designed from start to finish. As a tester you can do this manually (bore!) or you automate this!

E2e tests have many benefits:

Enables QA engineers to test more scenarios in a shorter timeframe

Allows QA and software engineers to understand how people interact with the application

Verifies that the back end and front end of an application are communicating effectively

Allows for a quicker feedback loop for bug fixes

The not-so-great side:

Needs a specific running environment

Can be difficult to debug

Requires maintenance

Can be flaky

May produce false positives, if tests are written poorly

If you are new to automation testing you have undoubtedly heard many terms and frameworks thrown around and it can be confusing. I’ll touch on a few as they relate to Protractor in hopes to provide a clearer view on how they work together.

Protractor is a Node.js program so you will need to have Node.js installed to run your tests. Node.js is a runtime program which will execute your JavaScript code in your automated tests.

Protractor is built on top of Selenium’s WebDriverJS. Selenium’s WebDriver is a web application testing framework that uses the browser’s native support to automate your tests. Within your e2e tests you will need to locate different elements using WebDriver’s functions, you can see a complete list of functions on the Protractor API page.

Selenium works for many programming languages and is used with various automation frameworks, it’s not specific to Protractor and if you’re interested in getting more into testing you should definitely dig deeper into this. Here’s a great post that goes describes the various Selenium projects.

Protractor also uses behavior driven development (BDD) frameworks to help write and manage your tests, the main three are Jasmine, Mocha and Cucumber. These frameworks are also based in JavaScript and Node and provide the ability to validate if a feature is working as it should. It’s easy to think about it like this: Protractor and WebDriver simulate the user’s interactions within an application and Jasmine/Mocha/Cucumber test that those interactions are implemented as expected. example!

Say you’re on a user input field with an option to cancel or publish. The user input feature has a verification step on cancel to confirm if the user would like to discard their changes. In your test you should expect to get an alert on selecting cancel and have your app redirect to the home page, if it doesn’t that test case will fail.

  var cancelAlert = browser.switchTo().alert();

Without Jasmine/Mocha/Cucumber your test will continue running and there won’t be any indication that the indented behavior was or wasn’t implemented.

You will only use one of these frameworks, I use Jasmine and it has served me well. I don’t have much experience with the other two but I think Cucumber has some interesting features that help those who aren’t working in a highly technical capacity to weigh in on test cases. Since it’s written in a pseudo-language it allows for other stakeholders to provide feedback earlier on or even allowing them to create their own test cases.

Now that you have a better understanding about the other components involved with creating your Protractor e2e test, let’s talk a little bit more about Node.js. So remember when I was talking about node being a runtime before? Well what that means is that Protractor, WebDriver, Jasmine/Mocha/Cucumber are implemented through Node as a runtime. Every language has some type of runtime system, in this case node is acting as a runtime system for these frameworks to interact with an Angular application.

Per Wikipedia:

The runtime system is also the gateway by which a running program interacts with the runtime environment, which contains state values that are accessible during program execution, as well as active entities that can be interacted with during program execution.

There’s a lot that can be discussed on all the frameworks touched on here, this is just a small glimpse into the world of automation. I will create more posts exploring these frameworks more in-depthly in time. For now I hope that this has cleared up some ambiguities for anyone starting out. If there’s anything that’s still unclear or maybe more so after reading this, let me know and I’ll be glad to explain it differently. If you have any resources on this topic that you’ve found helpful, please share!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.