Not so long ago I was asked to help a scale-up company find bugs in their Angular SaaS platform and try to 1-up their overall product quality. They have numerous big clients but the bugs are just waiting to pop up unexpectedly, waiting to hurt their overall platform image.
Great! So how would you for instance create end-2-end tests for it? Well, actually with almost any other website, you would’ve used Selenium. However, in the case of Angular, the guys at https://protractortest.org made an awesome framework build around Selenium to create your own tests for your Angular application.
As you might know Angular has 2-way binding so the webpage is dynamic. Protractor helps you with the painstaking task to wait for results to test on. So inefficient sleep functions are of the past.
In the recent weeks working for this scale-up I had some insights that really could help any new Protractor user. So here are my 5 tips. Most of the tips are not only Protractor test framework tips but also tips in general for your project. You’re free to ignore them but that might cause frustration later in your project 😶
Like any project your end-2-end automation framework will be under constant change. This means that new features in the system under test need (re)configuration in your test automation framework.
Create a “conf.json” file within your test framework and let it contain a lot of configuration variables your test framework can reference to.
For example, I used the following configuration json file to get all my needed variables. It contains important information like base url’s, menu navigation items, login credentials, which account to use at the start of the scripts, etc.
It is easy to just start writing your spec files containing every bit of needed code. But please don’t do this. Your code logic should be separated from the specification file. For almost each page and entity I wrote a separate class file containing all the code that can be used for it’s specification file.
This greatly increases readability of every specification file for yourself or your other team members. It also really helps the maintainability of your test framework. Because some changes on the website most likely will also cause changes in your test code.
Example of a file containing the logic:
Example of a specification file using the above logic file:
It is highly likely that the Angular application you’re testing uses constant background calls to update certain page elements on the fly. Even though Protractor has been created with this as its mindset to help testers with, some calls just simply cannot be handled by it. For instance, if the application is constantly http polling for new information to be inserted in the table on the page, Protractor doesn’t know when it should start running the next line of code.
It’s okay to take full control over Protractor’s approach to wait for results. It is even recommended to do so in the case mentioned above.
To fix this you need to use Async/Await in your scripts and use some clever expected conditions to look for specific elements. To be able to use any Async/Await, you need to disable the Selenium promise manager also known as the “Control Flow” in your Protractor conf file. The Selenium promise manager is deprecated so this is safe to do so.
My framework uses a “src” and “dist” folder. Where the former contains all the source code and the latter contains all the compiled TypeScript code from the “src” folder. Thanks to a simple Grunt script my “build-and-test” command copies important “conf.json” and asset files to my “dist” folder.
The following package.json runs my compile and build commands:
The following grunt file copies all my assets from “src” to the “dist” folder:
When using Jasmine with your Protractor test framework, you need to state some “describe” and “it” statements.
“Describe” always implies the topic or webpage part I’m creating tests for. Whereas the “it” statements contain a concise enough but comprehensive title about the action it should do and results it should achieve. If the title isn’t concise enough the test results will be harder to understand, for yourself, and the developer that needs to fix a possible bug.
It can be quite cumbersome to create tests and test titles like this at first but after a while it just clicks and you write tests that will hit a specific scope instead of a generic one. A huge benefit when writing your titles like this, is it also gives you insight in what you and the system under test are trying to achieve. This might even spawn discussion in your team/project and a better understanding of the system under test.
Let’s look at an example:
Great you’ve made it this far. This tip is a more general tip for you and your career. Keep yourself educated! It is really important! Just like you educated yourself by reading my post, for which I’m grateful, follow some courses on testing.
If you need inspiration as in what courses to follow, I highly recommend going for the base ISTQB Foundation course where after the new ISTQB Test Automation Engineer course can be followed. Both are really useful in giving insights in how to work better and smarter in your daily test work.
If you work in or near The Netherlands, take a look at https://improveqs.nl for some of their excellent courses by trained veteran test professionals and industry pioneers. If you do so, don’t forget to mention my name. That way something cool could be coming your way.
If you have any more questions or doubts, hit me up. We could grab a drink together in Belgium or The Netherlands, and talk about what keeps us busy as professionals. I would love to hear from you!