Vue Datatable Example

An article about building a JavaScript JSON server and front-end Vue interface to display it.

A great simple example for those interested in building pure JS web services.

appdividend.com/2018/06/07/vue-datatable-component-example/

CypressIO Simplifies Web App Testing

After discussing projects over the past week, one of the guys at Automattic brought up CypressIO.   If you’ve been following the recent posts on Lance.Bio you know that the path to running automated web testing has run from Selenium IDE, the QA tool of choice for the past few years for Store Locator Plus, to recent forays into Selenium Webdriver.      Webdriver is powerful but difficult to code and soon led to the discovery of WebdriverIO, then Mocha and Chai on top of that.      The new stack makes it easier to write more advanced tests than we could in Selenium IDE — but it was like pulling teeth to get all the right pieces installed and working.

More info, less pain

That is what CypressIO promotes on their home page.   “Test your code, not your patience.” and “No more async hell.”  — if you’ve gone through the Selenium Webdriver setup you’ll understand what both of these mean.   It takes several false starts to understand all the pieces you MUST install to get Selenium Webdriver working.  CypressIO has made it easy; it is even easier than they promote on their website with the most recent builds.

The CypressIO Test Execution Window

The Cypress Test Execution Window

I’ve only started simple test writing but in less than 20 minutes I had a fully functional test running with all the extras from a completely “clean” install base.    If you have NodeJS and NPM up-to-date and a faster Internet connection than we have in tech-orphan Charleston South Carolina, you can be up and running in 5 minutes.
Read More

WebdriverIO and Mocha For Better Test Reports

In a continuing series on using WebdriverIO with Selenium we are going to focus on getting better reporting output now that our environment is setup.  The previous article on setting up WebdriverIO should have you up-and-running with basic tests.   Now it is time to use some of that “Mocha flavoring” to get useful reports out of our tests.   WebdriverIO and Mocha gives you the tools to group together tests and report the results in plain text.

Adding Mocha to a test

Mocha adds a ways to group together our test units and send meta information out to the report modules that are employed by WebdriverIO and the default test runner, conveniently named “TestRunner”.   Nothing special needs to be added if you’ve setup the project and employed the Mocha framework as shown in the prior article.

Since we are using the BDD test style with Mocha we have two primary functions we want to employ.

BDD = Behavior Driven Development,  in case you were wondering.

describe()

This is the Mocha syntax that is used to group together tests.   The first parameter in that function is the plain text that will be used to describe what tests are being run.   The second parameter is a standard JavaScript anonymous function that will include the test code.    Typically you use a series of it() functions within.

it()

This is the Mocha syntax that describes each individual thing to be tested.    The first parameter is again the plain text of what is being tested and the second is the function that contains the code.

A simple example

This test is going to open the home page for the website that was configured in the wdio.conf.js file when we setup our wdio configuration.

This does nothing more than make sure it can open the site URL.

When the test is run we now get a more detailed report of what happened.

Here is a video showing how the test run looks compared to the standard non-Mocha version.

Optimizing JavaScript for Chrome

A recent discussion with a tech guru at Automattic posed a great question — how does JavaScript asynchronous processing work on a single-threaded app?  Great question, but before I found out how that worked I decided to refresh my knowledge on how JavaScript manages the call stack.   Turns out a LOT has changed in 10 years and it turns out Google’s V8 engine was launched.

What is V8?

V8 was very likely a result of Google Maps.    Google Maps was one of the most-used JavaScript applications to hit the Internet (and has been my primary focus for the past 5 years as part of my Store Locator Plus project).  The problem with Google Maps is that the JavaScript library behind it is HUGE.    So big that it crushed most browsers of the day.   Not only did laptops and mobile devices have far less compute power — the JavaScript engines were not very efficient.

Enter V8.   Back in 2008 Google launched V8 as a new JavaScript engine for Chrome.   They employed several tricks to speed up code execution making their maps, and every other JavaScript applet, run faster.     It also happens to have become the core engine used in NodeJS which has itself become another “killer JS app”.
Read More

Selenium on JavaScript : New WordPress Site Config Script

This article continues the journey into learning Selenium on JavaScript (SoJa).  It builds on the lessons of the previous articles and adds some common library functions to make our tests more readable and starts to employ the Don’t Repeat Yourself (DRY) concept.

In this case we are going to build a common library module that we will re-use in future scripts. It will load our configuration and environment.  It will also export some methods that make our test script code a lot easier to read. The configuration and environment setup functionality is covered in prior articles so we’ll leave that out of this discussion.

What This Script Does

This script automates the very first steps of setting up a WordPress site after the software has been installed.  We use this on our Store Locator Plus development systems after doing a “fresh install” of WordPress so our dev team doesn’t have to keep typing in the same 5 things over-and-over every week when we spin up a new release to be tested “from scratch”.

The script will select our language (English, the default) wait for the next screen to load and then type in the title of the site, our username, email, check some boxes and click the install button.      The other elements of setting up our site such as the database name, etc. has been completed as part of our base dev box setup so you won’t see that here.   You can easily extend this test to cover the other WordPress install forms.

The Scripts

We’ll leave out the configuration and environment scripts as they have been covered a few times in other articles. Our main test script and the common lib are below.

Main Test

Common Lib

Discussion

The Main Script

The main script itself is fairly self-explanatory thanks to our new helper methods in our common library.   The main script load the common library and assigns it to the local test variable.    That library has setup logging for us, the Selenium Webdriver, and some “nice to have” functions that we’ll get into later.

We output that our activate site test has started to the log window, load up our WordPress site URL with the get command and when the page is loaded click the continue button, wait for various form elements like the blog title to appear and fill it in.  We also click some things as well.

Simple, right?

The Magic, aka Common Library

The real magic happens in the common library.   It employs the tricks we’ve learned in previous lessons to build reusable code and make our main scripts easier to read.   It uses the standard NodeJS module export technique to define names for our methods as well as their functionality.

There are some things that are common for most web tests, type a value into a form field, click a button on a form.    We’ve added some “make this stuff behave” logic using the Selenium Promise-based style to ensure things are more stable than randomly typing stuff and hoping they are on our page.

Let’s review our new methods in more detail.

When ID Exists Type

This method is used to look for an input on a page by its HTML ID and type something into the form.    We could just “jam some key strokes” into a field and assume it is on our page.  However we often are waiting for dynamic JavaScript elements to appear on modern websites.   We also have pre-filled input fields like password suggestions to deal with.   Things are not as simple as they seem.

In this method we first tell Selenium to wait for the element to appear on our page.   Our wait loop will give the web page 6 seconds to present the element or throw an error.   That is the driver.wait() part with until.elementLocated() within.

If the element is located run the success function defined within the then() follow-on method attached to the driver.wait() call.

Notice we assign findElement() to var el.   Why?  We want to make sure the input field is EMPTY when we start.    We do that by click on the input field first, then clearing it out, then ending our value in as keystrokes.   This addresses any pre-filled fields like the WordPress password suggestion as well as any add ons your browser may be employing that auto-fill forms (if you did not disable them, which you should).

The when_id_exists_click() is the same idea as the input method but in this case we have less work to do since we are clicking a button and don’t have to clear the element out.   No need to explain further.

When Name Visible Click

This method is a bit different than the ID Exists Click or ID Exists Type methods.   While the concept is the same the difference is in the execution.    The Selenium until.elementIsVisible() method has been constructed differently than the other methods in the library.    This is one of those language inconsistencies, and every language has them, that drives developer crazy.

 

Many of the other until.blah() methods take a LOCATOR as the parameter, in other words the By.id or By.name method where the locator is what is being processed.   elementIsVisible() takes the actual web element itself.    It’s a gotcha that has tripped up more than a couple of Selenium coders.   It is why our Visible Click method is more complex.

To not repeat ourselves and ensure consistency we setup our locator in the by variable to locate an element by name.    We let the driver wait until our element is found by name on the page, using the standard 6 second delay.   Once we know the element is on the page we assign it to the el variable and then do another wait until the element is visible.

Remember, just because an element is within the web page (part of the DOM structure) it does not mean it is visible.   It is also important to know that many Selenium functions will NOT let you interact with an element that is not visible.

 

%d bloggers like this: