Late to the Party; End-to-End Testing: Part 3
Writing tests.
So far we have been mostly focused on details of interacting with Selenium servers. Wanted to briefly focus on writing the actual tests.
This article is part of a series on exploring end-to-end testing with Selenium and Node.js; starting with Late to the Party; End-to-End Testing: Part 1.
Writing Tests
In the end, the purpose of our code is to connect to a WebDriver interface (be it a browser directly or a Selenium server) and issue a series of commands and validating that the browser’s behavior matches our expectation.
Say we wanted to validate that searching the site https://duckduckgo.com for WebdriverIO returned a page with the title WebdriverIO at DuckDuckGo.
Building off our previous example we end up with:
hello.js
Observations:
- The only non-obvious command is the one with waitUntil. This implementation will try up to 3 seconds to repeatedly (every 500ms; default) get the browser page’s title until it matches WebdriverIO at DuckDuckGo; rejects the promise if it does not.
- The waitUntil command’s first parameter is a function that returns a promise (that is what async functions do)
By looking at Sauce Lab’s details on the test, we see what WebDriver commands ultimately got executed.
- POST url {“url”:”https://duckduckgo.com/"}
- POST elements {“using”:”id”,”value”:”search_form_input_homepage”}
- POST element/0.43490473879784086–1/clear {}
- POST element/0.43490473879784086–1/value {“text”:”WebdriverIO”,”value”:[“W”,”e”,”b”,”d”,”r”,”i”,”v”,”e”,”r”,”I”,”O”]}
- POST element {“using”:”id”,”value”:”search_button_homepage”}
- POST element/0.43490473879784086–2/click {}
- GET title
Again, it is the client (Node.js application) that does the actual determination that the test was successful or not.
Selenium IDEs
One of the pain points in writing these tests is quickly determining the appropriate commands and selectors for them.
While you can use your browser’s development tools to inspect elements to build your tests, there are two (that I know of) tools that help speed up the process.
The first is Selenium IDE; developed by the Selenium team; there is also a Firefox add-on.
The second is Katalon Recorder (Selenium IDE for Chrome); there is also a Firefox add-on.
At their core, they both operate in much the same way. You visit a website, activate the tool, start recording, interact with the browser, and then stop recording. The result is a series of WebDriver commands that you can implement your in your tests.
For example, using Selenium IDE or Katalon Recorder we run it through our DuckDuckGo example above and the commands.
command: open
target: https://www.duckduckgo.com
command: type
target: id=search_form_input_homepage
value: WebdriverIO
command: click at
id=search_button_homepage
One nice feature of Katalon Recorder is that it can export the recorder as a test in various languages / webdriver library / frameworks. Unfortunately, JavaScript is not one of them.
However, one of the export options is XML that you can use as a hint when building your JavaScript / WebDriverIO test.
The challenge is then translating the commands into WebdriverIO code.
Next Steps
We have successfully written a single test (with an implicit assertion). In order to write a suite of tests with more complex assertions we will want to introduce a testing framework and assertion library. In the next article, Late to the Party; End-to-End Testing: Part 4, we will do just that.
✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.
