Using Faker to generate data for your Cypress tests

I’m a man of simple pleasures. Good books to keep the mind active and exposed to fresh ideas. Music that I can enjoy and relax to when needed. And also doing things with as little extra effort then required. Or sometimes referred to as taking the path of the least resistance. Why push a boulder up a hill if you don’t have to?

One of my favourite quotes by Bill Gates touches on this very topic and I think it illustrates perfectly the mindset that I try to apply to my daily life.“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”

“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”

Bill Gates

Lazy seems to have a negative association in today’s society and coupled often with the image of someone laying in a hammock and snoozing the day away while avoiding more important work.

The word originates from the 1540s word lasey whose original definition was someone that was “verse to labor, action, or effort“. And despite the modern-day connection with the word idle and the associated images that it brings to mind. I’m happy to associate myself with at least part of the original definition.

Because like I say. Why do something the hard way if you don’t need to?

If you have read my previous posts on Cypress in which I detailed how to do API testing and showing the advantages of using fixtures and the custom command feature that Cypress provides. My goal in those posts was to shed light on the power that Cypress has to make our lives as Software Testers and Automation Engineers that much easier.

In this post, I want to focus on another aspect of Cypress, one that is often used to change and extend the abilities of the framework to fill our desired needs. And much like I did in the previous blog post. I will take the example of registering for a new web application. Feel free to use this technique for your own requirements and tasks like filling in and submitting web forms. Or transferring an amount of data to a server.

While it is critical to design a test that exercises your UI flow for registering users to your applications. If you need to create 10, 50, or even 100 user accounts to perform your desired test cases. Creating 100 accounts using a web form is unnecessary and expensive. And along with being a huge time sink, it only takes away from the time available to perform the testing activities that provide actual value.

So for this example, I will make use of an API to register our users. And like previously, I will use the API provided by Docket to show these capabilities.

You can find the full code for the example here and the supplementary code to my previous Cypress posts on my GitHub.

/// <reference types="Cypress" />

describe("Docket Post Test", function () {
    before(function () {
        cy.fixture("user").as("user");
    });

    it("Register a new user", function () {
        cy.apiRegister({
            username: this.user.username,
            email: this.user.email,
            password: this.user.password,
        });
    });
});

Here I am calling the data I want to use in my test case from the stored user fixture file (read my post on fixtures for a quick brush up!) And then passing that data to a custom command which I have written to register users to the Docket application (you can read about custom commands in the same post).

Now, this is ok for X number of users. Or those accounts we know that we want to register, or have the test data for.

But what about if we want to create hundreds of users to simulate a certain event or test the limits of our database 🤔

This is where libraries like FakerJS will generate a vast array of fake data for us, including people’s names, address, animals, and even a mustache (note: investigate this).

You can install FakerJS by entering the npm command npm install faker --save-dev but you might wonder how you can make use of it in your Cypress tests.

This is done by the use of Plugins, which as I mentioned earlier. Provides a way for us to enhance and extend the capabilities of Cypress. Provide us with a fresh user object with unique property data for our tests.

There’s an extensive list of useful plugins listed on the official Cypress site. So before writing your own plugin I recommend looking through the list of available solutions first. You don’t want to be reinventing the wheel.

To write a plugin, simply navigate to the plugins/index.js file within your Cypress directory.

We simply need a way to call it and then define the plugins purpose and the operations it should do.

on(<how you will call it>, {
        taskName() {
            // do stuff
            };
            return ??? ;
        },
    });

So for our purposes of using faker to create a new user object. We need to import faker first and then write our plugin.

Here’s one I did earlier:

const faker = require("faker");

module.exports = (on, config) => {
    on("task", {
        freshUser() {
            user = {
                username: faker.name.firstName(),
                email: faker.internet.email(),
                password: "SuperSecret",
            };
            return user;
        },
    });
};

(I’m using a static password just in case we need to access the test account later on).

Now we can make use of it in our tests, like so:

/// <reference types="Cypress" />

let user;

describe("Docket Post Test", () => {
    before(function () {
        cy.task("freshUser").then((object) => {
            user = object;
        });
    });

    it("Register a new user", () => {
        cy.apiRegister({
            username: user.username,
            email: user.email,
            password: user.password,
        });
    });
});

Now each time we run the test. We are injecting unique data and a user with distinct and valid credentials is being registered.

And to extend it further to make this test generate as many test accounts as we like. We can modify our spec file to make use of JavaScript’s looping abilities. Thus rerunning that test until it has run for how many times as we have specified.

However, I suggest implementing a delay if you do this so you don’t flood the server with registrations!

I hope you found this post useful. You can find the code for this example on my GitHub and if there’s a Cypress concept or a Test Automation topic you have a question on. Reach out to me on Twitter, LinkedIn, or via my contact form.

Posted by Kevin Tuck

Kevin Tuck is an ISTQB qualified software tester with nearly a decade of professional experience. Well versed in creating versatile and effective testing strategies. He offers a variety of collaborative software testing services. From managing your testing strategy, creating valuable automation assets, or serving as an additional resource.

Leave a Reply