Debug Protractor Automated Tests under Webstorm

The best way to handle the situation in which an application it’s not working as expected is to debug it. Test applications are not an exception to the above.

Debugging automated tests assures that the tests behave as intended and avoid false positive / negative results. But sometimes, configuring debugging in your tool is not straightforward. I’m going to show you how to configure debugging for your protractor tests in WebStorm.

“Can the tests be trusted?” is the most common question the development team asks when automated tests are added to the Product Delivery Pipeline. Debugging is a handy way to validate behaviour of the tests, and it can be done easily with a minimum configuration.

Pre-requisites:

  • Webstorm
  • NodeJS 6.x.x
  • ProtractorJS

Steps:

  • Within Webstorm, create a new Run/Debug Run Configuration
  • Edit the following fields of the Run/Debug Run Configuration:
  • “Node interpreter”: absolute path to local installation of NodeJs
  • “Working directory”: absolute path to Project directory
  • “Javascript file”: relative path to protractor cli.js file
  • “Application parameter”: relative path to protractor configuration file

To debug your tests simply place breakpoints in any place needed within the code and use the above Configuration to debug. One advantage here may be the fact that if tests break due to an invalid value, you can place a breakpoint and change the variable value using the console or the debug tabs and give it a try live.

About two years ago I was starting to write ProtractorJS tests for the first time and faced issues I never imagined till then. Difficulty of debugging JS async code was one of them. After some research, I’ve learned how to do this which helped me in some weird situations. One of them is the false positive test result.

You have the following piece of code:

webElements.searchResults.each(function(element){
element.getAttribute("innerText").then(function(text){
expect(["api","guide","tutorial","misc","error"]).toContain(text);
})
});

Now, imagine the situation in which the searchResults is an empty array of elements. Your inner code will be ignored and the test will pass. The search results are in the page but not tested because you may have used an invalid identifier. Placing breakpoints within the code will reveal the issue and will give you the opportunity to test the identifier used.

Fake positive test results

Hot changing the identifier with a correct one will give you the chance to execute the inner code where you can see in real time the element attributes including the one we need: ‘text’.

Reveal the issue

Hooray to the debug process as we won’t have to rerun the test over and over again to spot each place the tests fail as we do changes one at a time. Now, within a single run, we can fix multiple code issues and quickly deliver trusty, good quality tests.

The demo code can be found here.

Conclusion

Debugging is a good way to quickly identify miss-behaviour of automated tests and to ensure that they work as expected.

Considered as being hard to do under ProtractorJS, a lot of teams give up and start automating things using other tools like Selenium under Java where debug is considered to be more handy. I hope this article will put a question mark on these kind of decisions and teams will be able to fully take advantage of the integration between AngularJS and ProtractorJS, mainly in AngularJS 2 where the two integrate more.

Let us know how you debug your tests.