In this post I’ve decided to show you a simple way to start with writing tests for webapps in BDD style. Tests on mobile apps can be run in a very similar fashion using appium.
WebDriverIO <=> Selenium Standalone <=> Firefox/Chrome/PhnatomJS
First of all, make sure you have node and npm updated to a recent version and install all the deps that you wish to use, you can take a look @package.json to get a grasp of the packs I’ll be using . After that, you need to create the config for webdriver. You can use the command
>wdio config and follow the steps; most likely you will need to tweak the generated config a bit to match your needs, but it’s nothing fancy. Choose whichever browser is installed on your system, among phantomJS, chrome and mozilla. One can even run multi-browser tests which is probably the best option. For demonstration purposes, in this post I will go with chrome. The application for testing can be found in my previous post. To be honest it’s not the best candidate since the hydration takes way too long because of JIT compilation, but let’s give it a shot anyway.
After creating -optionally- the gruntfile and .babelrc we are ready to start. First I will create a main page object from which all page objects will inherit from. In loginPage.js there’s an extended class LoginPage from Page, containing the selectors as getter functions. In this case, getters are quite essential since I want to make sure that functions get invoked every time the property is requested, providing the element before any action is done on it. Furthermore I will need to invoke the superclass’s method open in order to navigate to the specified path. There is also a submit method, which as the name implies, is used to click the button ‘Submit’ after entering the credentials. In the end I choose to export an instance of the LoginPage.
In order to keep this post brief, I will show you how to test login’s form submit. Let me create a tests.js containing the tests that I want to run. Simplifying the task I assume that a binary test (e.g. correct-incorrect login credentials) in our case is sufficient enough. So here we go.
Firstly, what I want to do, is to import LoginPage and define a function with arguments like username and password. So, I request the baseURL + /login page and after that I tell the browser to wait for max of 50secs till the img element appears. Next I fill in the credentials and submit the form. The ternary operator is used to check whether the warning span appears and returns the state. If no span appears then it means the user is logged in. But let’s double check that; should a user be logged in, then in the application flow a navbar must appear too. The penny drops when you realize that you can write your tests in multiple ways, choosing what makes more sense to you. What’s more using Mocha and Chai, as you can see, things get really verbose.
At the end of the day, it’s worth to point out that the stack used has a really flat learning curve making it extremely easy to write end-to-end tests. After reading the documentation you’ll be going great guns. Here’s the final result after writing some more lines.
 You can easily find the XPath or css selector; just right click on the DOM element and select ‘inspect’, right click on the highlighted element in DevTools, and in the menu that pops up select copy and choose the appropriate locator
 For debugging purposes you can use chrome dev tools in node, just add this line execArgv: [‘–inspect’] in your config and you ‘re ready to use the console