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.
Debug Protractor Automated 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 had never imagined till then. Difficulty of debugging JS async code was one of them. After some research, I learned how to do this which has 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.
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’.
Hooray for 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 make changes one at a time. Now, within a single run, we can fix multiple code issues and quickly deliver reliable, quality tests.
The demo code can be found here.
Conclusion
Debugging is a good way to quickly identify misbehavior of automated tests and to ensure that they work as expected.
Considered difficult 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.
