Beginning Protractor: Introduction
In this introduction, I talk about the motivation to write this article and what we should strive to achieve with Protractor!
Within the last year I’ve worked with a lot of Protractor, and everywhere I go I see it used completely differently. Some practices I’ve seen are great and I wish more people employed, others I wish to never see again until my last day. Your code base might have these horrible practices if:
- Adding just one test takes you an hour, then getting everything to work together takes the rest of the day
- You wanted to add a feature but your function is slightly different so you have to add a new one while repeating 95% of the preexisting code
- The code is a jumbled mess of Promise Hell which causes your mini map to look almost topographical
Am I being dramatic? Maybe. However working in Quality Assurance you realize that sometimes people writing these tests just don’t know Protractor. This is a problem, and one I hope this series of articles will help solve for those seeking to improve their Protractor game.
For applications with extensive amounts of tests, its crucial that the Protractor code be maintainable, scalable, and focused.
You may have heard these terms used differently around the internet, but let me define them as I intend them to be interpreted.
Maintainability is the ability to refactor preexisting code without creating breaking changes throughout the environment.
Scalability is the ability to easily add more features to the existing code as the application grows in size.
Focused Protractor code is always direct, relying on branching statements as little as possible and keeping the scripts oriented on a single purpose.
To get our code base to this point we’re going to need a solid understanding of what Protractor is, how it works, and how to best employ it to test your application! This is only the intro, so stay tuned for Part II: Understanding Protractor.