My journey in learning all about UI Automation and Protractor
An insight into the Trade Me end-to-end automation tooling used for our Angular app and my journey in learning all about it.
Along came a (Pro)Tractor
It all started back in October 2018, when my squad ended up being one of the first squads brought on board to start working on Trade Me’s new responsive mobile site. At this point, the site had the bare bones and so now it was time to build all the fabulous features our users love about the Trade Me experience.
The new website is an Angular app, and we decided to write end-to-end (E2E) automation using Protractor. Protractor is an E2E test framework for Angular and AngularJS applications which runs tests against your app in a real browser. It essentially tests exactly what your users would experience when using your app.
At Trade Me we already had extensive usage of API Automation test tools, but we were collectively less familiar with UI Automation. I myself, had no experience in UI Automation. Even working 100% on the Front-end was new to me. However, I’ve always been up for a challenge so I took this as a great opportunity to learn about both UI Automation and Protractor… I was excited!
Some insight into the tooling
At Trade Me, we use Protractor mixed in with Tractor which is a UI tool that was built by the amazing Craig Spence and is built on top of Protractor. As quoted from the Tractor github repo, Tractor is “a UI around Protractor to help write E2E tests for Angular applications without needing to know JavaScript”.
So you’ve got full access to the code and 99% access to using ‘pure’ Protractor. One of the perks of having a UI for Protractor is that anyone can jump in and create tests easy-peasy, without needing to know Javascript. All you need to know is a little bit of CSS, a little bit about automation, and a little bit about how page objects, mock requests and mocha specs work together and you’ve got yourself a shiny e2e test.
You can do all of this using the Tractor UI as shown below:
Under the hood Tractor is translating what you create into JavaScript. For example you can put in your Elements and Actions into your page objects like below:
And Tractor will translate this into code like so:
this.refinementOptionAccordion = function (groupSelector) {
return new Tgbutton2(findAll(by.css('.tm-refine-menu__reveal-accordion-item')).getFromGroup(groupSelector));
};
};
TmRefineMenu.prototype.clickRefinementOption = function (nameOfRefinement) {
var self = this;
var result = Promise.resolve();
result = result.then(function () {
return self.refinementOption.clickRefineItem(nameOfRefinement);
});
return result;You’ve also got tabs for Mocha Specs and Mock Requests too. Within each of these tabs you can do all of the below and more:
- Create new files
- Create elements in the page objects files
- Add actions to the page object files
- Pop in your json for mock request files
- Pull it altogether in the Mocha spec files to create e2e tests
How it began
I jumped in head first. While the devs were upskilling in Angular and TypeScript I took advantage of the extra time on my hands to upskill in Protractor and Tractor.
I started off with learning how it all worked and what all the pieces of the puzzle were; page objects, mock requests, mocha specs. I then jumped in and took a look at the hundred or so tests we already had and thought:
- Where can I add more value to our tests?
- Are all of these tests still valuable?
- Can I improve any of our current tests?
- Do we need more coverage of the app?
With all of the above to consider I had an endless supply of ways to upskill in Protractor.
Developing my JavaScript skills
There was an endless supply of chances for me to upskill and learn Protractor. However, for me the Tractor UI was just a step in the journey towards becoming more technical. In particular, it offered a great step towards learning JavaScript.
For myself, I did this by having my IDE open alongside Tractor. I’d make changes in the UI, and watch what happened in the source code to better understand what was happening.
I then stepped things up a bit from there and started learning JavaScript, so that I could start making changes directly in the code rather than relying on the UI wrapper that Tractor offered. I’m still learning, but I’m at a point where I’m getting more comfortable with writing tests in JavaScript, and even more comfortable with reviewing other people’s code changes!
The training part of it all
Me being me, I soon became super familiar with both the tooling and the authorship of automation tests. So I somewhat naturally ended up becoming the go-to person for all things Protractor and Tractor. This then moved to me being asked to run training sessions which I felt was a great compliment to all my learning. From there, I’ve done more and more stuff so I’ve now had the chance to:
- Improve our tooling and how we run tests
- Debug and fix tests
- Mentor others in using Protractor and Tractor
- Run training sessions to upskill others
- Review a bunch of code changes
- Develop my JavaScript skills
I never would have thought that I’d end up becoming the person who trained others in the art of Protractor but anything’s possible if you put your mind to it. Best of all, I’ve improved a bunch of other skills too, such as communication, documentation, public speaking, influencing others, and mentoring.
What’s next
From all of this, I’ve now realised that I quite enjoy the automation part of my role. Plus, being able to share what I’ve learned, and coach others is pretty rewarding too.
Best of all, I like how automation allows you the opportunity to get into the code, to learn it, understand it and write it. Just knowing how things work from the lowest layers through to the top-most layers is super interesting to me.
So at this point I’m pretty certain that automation is an area that I’m keen to specialise in at some point in the future. For now though, I still have a lot more to learn, so it’s just onwards and upwards from here.
