My experience so far in development roles has been with the .NET stack so when I was asked to pick a tool to implement UI automation, I had using Selenium and C# in mind. However, due to the technology of the systems I was automating, I decided to investigate Protractor.
Things To Consider
I must admit, I was pretty hesitant about trying Protractor. But, I had a number of factors to consider which meant that I had to give Protractor a chance.
I needed to make sure that the tool that we selected fulfilled the following criteria:
- Setup and writing the tests needs to be implemented quickly
- Needs to be able to implement a good and extendable project structure
- Needs small learning curve as the team are both new to the company and will have enough new tech to learn
- The tests need to run faster than it takes to run them manually
- Developers need to run these tests via command line
- Results need to be displayed clearly
Setup and writing the tests needs to be implemented quickly
This was important because we are only a small team and we have a lot of work to do now and in the future. Being able to set up the test frameworks quickly will means we can get this done and be confident the areas tested by the frameworks is covered leaving us with the manual tests and exploratory.
Setting up a Protractor project
Luckily, setting up Protractor was extremely simple. Using the following 3 lines sets up Protractor easily (you do need to have npm installed first but if you don’t, that’s another quick installation).
npm install -g protractor
webdriver-manager update
webdriver-manager start
Installing Selenium into a project
Thanks to Nuget Package Manager, installing Selenium is now a lot easier than when I first started automation.
You just need to install the Nuget packages, Selenium Webdriver, Selenium Support and WebDriver.ChromeDriver into your project. Once you have these, you are ready to go!
Needs to be able to implement a good and extendable project structure
At this early stage in the company, we’re not sure how many more that’ll be added to the team. However, it’s important to create a framework that can be extended and easily maintained.
I’ve been using the Page Object Model design pattern to structure my project. I’ve done this because it’s easy to read, easy to replace classes and methods, and everything is contained and broken down into small bite-sized chunks. So this is (basically) the structure I have been using for my project. I’ve got a few minor objections to making the Page classes static, so I haven’t followed this to the letter, but the principle is there.
Creating a good Protractor project structure
I found that the examples of using the Page Object Model design pattern were a bit misleading.
The point of using this pattern is to separate the functions into different files so that everything is less dependent and extendable. However, the examples of this had all the code to run a test in one file. So it was good if you wanted to learn the basics of the page object pattern but not if you wanted to use it properly.
I set about implementing this in the way that I am used to and then I ran into some issues when trying to separate these out into different files.
After I overcame these issues, I learned that if you want to use functions from one file in another, you need to add this into the main function of the file that’s referencing the function:
var homePage = require('../Pages/HomePage');
You can also add this at the top:
require('../Pages/HomePage');
Then you need to add this at the end of the file that contains those functions:
module.exports = new HomePage();
This allows you to use the “require” command to call that file and enable it’s functions to be used in other files.
Once I got my head around this, I used the examples of locators on the Protractor website to quickly write the bulk of my tests.
Page object model and Selenium
Because of my experience with C#, setting up the Page Object Model in a C# project was a lot easier. Plus, there are a lot of experienced automated testers out there with video tutorials to help if I ever got stuck. needless to say, there was no issues putting this together.
Needs a small learning curve
As our team is new to company and will have enough new tech to learn, it’s important to make sure the tool isn’t too complex to learn or it’ll eat into the time we need to spend doing other things.
Struggles with Protractor and JavaScript
The team were all unfamiliar with JavaScript so progress was slow to say the least. I got tripped up a few times with the unusual syntax, as I haven’t used it for years.
Using the protractor commands, like locators was also new. So even though the framework was built on Selenium and locators looked familiar, implementing them still want straight forward. Despite knowing what i wanted to do with a locator, I had to keep looking up the correct syntax to add them to my test.
Using asserts that aren’t standard to MSTest or NUnit was also took some getting used to and lots of searching on Google.
There’s no doubt a steep learning curve here. Not complex, but just time consuming. And I’m not certain whether I or my team, have enough time to learn all of this as well as all the other parts of the system and tools in this new company.
Learning curve with C# for my team
Putting my own selfish reasons aside, my team is used to using object-orientated programming languages. So picking C# to carry out the automation, was a lot easier for them to pick up and progress using.
This smaller learning curve also made this switch a much more enjoyable experience for my team.
The tests need to run faster than it takes to run them manually
The reason why we automate some tests is because these tests are run repetitively, they’re setup is rather complex to carry out every time or they take a long time to run. So, making sure the tests that we write run faster than if they were carried out manually is highly important. If not, we’re wasting time, not saving it.
Speed of Protractor tests compared to Selenium
I must say, the small amount of tests that I have written are run very fast using Protractor. Unfortunately, out of the box, Selenium is a lot slower.
For this comparison I ran the same amount of tests for each project. The Protractor tests ran for approximately 13 seconds while the Selenium tests were running for over 40 seconds 🙁 There are ways around this like that I have investigated like, running the tests in parallel (which reduced the test time to around 16 seconds) and other ways to refactor the code to improve the performance, but clearly Protractor wins by miles in this aspect.
The Choice I Have to Make
The decision that I have to make is whether being able to implement tests faster, but slower running tests is more important than implementing tests slower but that will run faster.
Using Protractor has been a roller coaster ride so far that I think will only get progressively more difficult before it gets better the more I use it. I did get through it though.
There’ll always a little nagging voice at the back of my mind telling me that this will be so much easier with Selenium and C#. However, learning how to implement Protractor has expanded my testing capabilities already. And although the tech of the project shouldn’t dictate the testing tools you use, I think trialing this was beneficial to at least consider the potential benefits.
Overall, I’m leaning more towards sticking to what I know. Performance improvements are always being made to tools. Selenium tests may get faster in the future and if not, there are a lot of performance improvements and code refactoring that I can implement to help with this.
