By
: Daniel Guzman – GlobalNow Senior QA Automation Engineer
Whether you are a developer or the architect responsible for deciding the stack of tools and languages to build your functional test framework, the following may motivate you to write your UI automated framework in NodeJS with WebdriverIO – by outlining the benefits of using a full stack approach.
My introduction from my “0 out of 2” experience!
I will never forget that moment, when I realized I knew “0 out of 2”, instead “1 out of 2”. Let me explain it: As a QA Automation Engineer, I was told to develop a testing framework for web and mobile platforms as part of my first project at my new position at GlobalNow IT. I wanted to quickly build the basis of a web system, in order to have it running, and then analyze deeper the best mobile language and tools to use based on current technology.
I initially understood that .NET would be the selected framework for this, so after putting together a simple test with Selenium, C# and Visual Studio, and showing it to the team, the project architect gently tells me I am not allowed to develop on C# or Java (which were the two main programming languages for which I am most experienced). Instead, I was asked to write our test framework in NodeJS. Yes, I was in that spot when had to start using and analyzing new technologies not only for mobile, but now for the web as well.
I was a bit discouraged and nervous, since I wasn’t really a JavaScript guru prior to my new position. (I am not one now either… yet) I asked our project architect, why NodeJS? Why slow down delivery by requiring me to learn NodeJS to build our web test framework? He provided a couple of good (and typical) business reasons; he was in charge of ensuring the project spends the least amount of money and to ensure we follow the same stack of tools across the project portfolio. The project base code was built in NodeJS, so having the automated tests in the same language was the best option.
This was the beginning of a new concept for me, as I started to realize this standardization process was not just based on someone’s whim or personal technology preference. But based on good reason:
The adoption of technologies and tools which use JavaScript is growing. Nowadays JavaScript is not used only for frontend development, but also for back-end services, and it seems even easier to write unit tests with it. So why can’t we just have all in the same language, by developing Functional tests in JS as well?
In one of my previous jobs, we had a situation where the front-end engineers weren’t able to add functional tests or provide much QA assistance, as our test suite was developed in Java.
This is a great blog entry from earlier this year from Mek Stittri, 2 January, 2016, https://medium.com/@mekdev/moving-to-node-js-with-selenium-starting-the-journey-19f5ab547e44#.qjl9znexa,that speaks to the these types of dilemmas, and the advantages and challenges of going Node.JS full stack with Selenium.
Mek’s blog does a nice job of reflecting the trend over the last several years, and how there is a significant movement into a Full Stack NodeJS world. So, I wrote this post not as an argument for moving this direction, but just to share how I discovered this new model, and that this transition is already occurring and becoming more popular.
WebdriverIO
So after you consider your options, and want to give NodeJS a try, you will probably face many options in regard to the base frameworks to work with. Of course I recommend to proceed with the one that best meets the business needs, but I will focus on the use of WebdriverIO, telling you why I went this direction, and hopefully my experience can help you in some way.
Out-of-the-box synchronic calls. I think this is the biggest concern I had when I started with NodeJS, asynchronic methods seem to always be a mess, difficult to debug, and in our automated world – are our enemies, as we should normally wait until a process is finished, to continue with tests steps, to avoid errors. Well, the async handling of commands is taken care of in WebdriverIO.
These are main reasons why I stayed with it:
- Out-of-the-box Sauce Labs runner service – to run tests on Sauce Labs, Browserstack. I found some documentation to get CrossBrowserTesting.com in place, which was pretty straight forward.
- Out-of-the-box parallel test runner (wdio) – to run tests across multiple OS/Browser mixes in parallel.
- A rich set of APIs makes the test code short and concise. For the project website, it is just very well documented, so you can development easily new tests and steps, and also have a great reference source, when setting up the basis of the framework, such as tests reporters and cloud services.
- Page Objects Pattern. Fairly simple model that always exports an instance of the page object class, which means you don’t have to create the instance explicitly, as you have stateless construct, in the same way as each http request is a stateless construct.
- Community, Gitter channel is just outstanding, Christian Bromann, WebdriverIO dev, replies in a matter of minutes, and not just saying “I got your message”, he seems to always have a solution, and if he does not, he creates a ticket to push it, and we can have it in next release, pretty cool.
References:
https://saucelabs.com/blog/accelerate-multi-browser-testing-using-sauce-labs-and-webdriverio
SIgn up