Thoughts on Software Engineering

JavaScript with Sinon for AJAX Testing: How to Wait for the Request to Complete before Execution Assertions?

In the Software University (SoftUni) we are developing a test automation system (online judge) for JavaScript code. It supports many languages and frameworks (C#, Java, JS, PHP, Python, SQL, C++, …). The interesting case now is with JS testing with Node.js. Students submit their JS code, the judge executes a few tests and responds with evaluation score (0…100):

Automated JS Testing with DOM and AJAX

Testing plain JS functions in the judge system works pretty well in production for many years, but now we are extending the system to support JS UI testing with DOM and AJAX requests, with frameworks like React and Angular. Students submit end-to-end JS single-page apps (ZIP file with many HTML and JS files) and the judge tests them automatically (without human touch). In its simplest form, testing JS code that invokes AJAX and changes the DOM works as follows:

Create a DOM tree with jsdom. Note that jsdom is not a fully functional browser. It is just a DOM implementation without navigation and is not 100% compatible with Chrome / Firefox. We use some hacks to provide objects like Option, HTMLLIElement and many others.

Put some HTML inside the jsdom’s document object, e.g. a form with a [Load] button.

Mock the XMLHttpRequest with Sinon, in order to intercepts all AJAX requests and return a fake HTTP response depending on the HTTP request content.

Execute the JS code, submitted by the student. It generally attaches event handlers to some DOM events, like click on the [Load] button, click on the [Login] link or submit a [Search] form. The event handlers in students’s code invoke an AJAX requests (asynchronously) and modify the DOM tree to display the results. In the general case student’s code may perform several AJAX requests and update the DOM tree several times. It is unknown when this process in completed (e.g. how many time it will take to perform the [Load] button’s action).

The tests in the judge system perform a DOM interaction, e.g. simulate a click on the [Load] button.

The judge system waits for the student’s JS code to complete and to modify the DOM tree, e.g. to display some data from a REST service.

The judge system checks whether the data in the DOM tree is correct (performs Mocha / Chai assertions).

Waiting for Asynchronous AJAX Requests + DOM Updates to Complete without having a Promise

The big problem here is at Step #6 from the above testing process:

How to wait for a JS event handler (e.g. button [Load] event handler) to complete all its asynchronous work (e.g. perform a sequence of AJAX request and render some HTML) before proceeding to test assertions?

It would be easy if the event handler returns some kind of promise, but this is not the case. We have a JS application holding some forms, buttons, links and even React components. We know that the app handles the buttons / links clicks and form submits somehow, but we don’t know anything about the code behind these events. The app code is black box. The only thing we know is that the application will invoke one or several AJAX requests, will asynchronously get some data from a REST service (which we mock with Sinon) and that the received data will be displayed in certain page element in the DOM. This could take 5 ms, or 50 ms or 3 seconds – we don’t know how many time. We don’t have a good indication when the operation is completed. Possible solutions:

If we ask the students to return a promise from each event handler, this will significantly complicate theit work. It is unnatural for a button event handler to return a promise.

If we use a timeout and perform the test assertions after 50 ms or 100 ms, this is not reliable. It may happen that the operating system is busy and these 50 or 100 ms are not enough. Additionally, this will make the testing slow.

If we listen for DOM changes (e.g. with a MutationObserver), this is also unreliable, because clicking on the button could change the DOM many times. For example, the button event handle could load asynchronously some data with AJAX, then display it n the DOM, then make another asynchronous AJAX request, then display it in the DOM and thus the DOM will change several times.

Node.js event-loop handles inspection – this is our reliable solution. Node.js provides an unofficial API for reading its event-loop: process._getActiveHandles(). It returns the list of active handles in Node.js in the event queue: unfinished timers, open sockets, servers listening for a connection, file system descriptiors, etc. You can list them using wtfnode.

The Solution: Waiting for Asynchronous Event Handlers to Complete Their Work

Finally, we have a stable solution how to wait for a event handler to complete all its asynchronous work. It relies on process._getActiveHandles() to take all active event-loop handlers, then takes all the timers and waits (with 5 ms polling) for all the timers to complete their work (except the timer used for polling).

This approach works reliably for server-side AJAX code testing with Node.js, jsdom + Sinon mocking. It waits reliably event handlers that perform multiple AJAX requests and update the DOM tree multiple times with internal delays. See the JavaScript code below for fully working example. The code below tests a function that is invoked when the [Load] button in a HTML form is clicked and asynchronously loads GitHub repositories and displays them 1000 times (to simulate a huge DOM update), then invokes another AJAX request to display a status from GitHub.