Lance Cleveland

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.


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.


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.

Setting Up WebdriverIO For Automated Website Testing

I’ve been writing about Selenium IDE for years , telling anyone that would listen how it helps automate user experience testing.    Recently , with the demise of Selenium IDE along with the engine updates to Firefox, I started talking about migrating to Selenium Webdriver.    Think of Selenium Webdriver as the “professional version” of Selenium IDE.    It is far more powerful but is a pain to setup and does require minimal JavaScript coding skills.

By installing a few node modules on my laptop I now can write fully UX tests in JavaScript using simple language without the need to work with external services.   Install node, install a handful of NodeJS modules, run the WebdriverIO config and you are ready to write some simple tests.

First things first -let’s get setup.

Read More

Improving wp_delete_post in WordPress Core

One of the common processes that runs in Store Locator Plus is deleting locations.    For sites with a few dozen locations the process runs smoothly.  For sites with thousands of locations but deleting one or two at a time, not a big deal.   But for sites that are deleting tens-of-thousands of locations at a time the process becomes painfully slow.   A mere 2,500 locations can take up to a full minute to be removed on a fairly decent performance server.   That’s not the type of performance I like to see from our product.

After digging into the performance of the PHP stack initial indicators point to the custom post types as the primary culprit.   It turns out that deleting a single custom post type in the WP_Posts table runs through a dozen gyrations to delete the post.  Multiple filters are called, associated taxonomies are delete, taxonomy meta is deleted.  It is a TON of extra overhead.    But even with removing records from a half-dozen tables the data queries seem out-of-control.

Removing just 9 locations generates over 190 data queries.     If there is one thing that has not changed in decades of writing software it is that data queries are costly.  They may run on solid-state drives with advanced memory caching but doing 190 data queries is still far slower than nearly any other part of the application.
Read More

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

%d bloggers like this: