Some in-the-trenches tips/experiences with React/Jest (autotesting)

I love React, and mostly like Jest (and Jasmine and Java predecessors) but I will say: I spent a WAY MORE ENORMOUS time chasing simple debugging of jest scripts. Simple stuff.

Why? I really dont know. It wasn’t designed for what I really want. It is designed for HUGE systems (like Citibank, Bank America, Amazon) to test a million things largely in-parallel across zillions of scrips and sorta-expect a reasonable failure rate (10%? more?).

My world is more simple (but still involved apps).  I dont want a single failure, at all. And I dont need to test a billion things in parallel, so I *fight* the Jest/Jasmine ‘reporting’ which buffers up your debug/prints and you’re basically lost…when All you really want is a simple test-runner, print-out my debugs, and STOP if error.

Hard to do with React/Jest but I’ve come close, so I’m sharing.

First, in your package.json, I do the following:

   “test”: “react-scripts test –env=jsdom –bail=1 –verbose=true –runInBand”,

I have no idea if this helps, but it tries to tell the test framework to “no do a million things in parallel” and “stop!”.  But that’s not enough and frustrated me. So, I learned more.

It’s called “fast fail”. Here’s what I do:

  • npm install –save-dev jasmine-fail-fast
  • Then, in the very top of your test suite, do:
    • import * as failFast from “jasmine-fail-fast”;
    • const jasmineEnv = jasmine.getEnv();
    • jasmineEnv.addReporter(failFast.init());

Now, when a test fails (that is an inner it() type of test), it SHOULD stop!! Which is what I desparateloy needed so that I could see any of my traces and learn the issue.

Next up: PrettyDOM

I have spent enormous time chasing errors where the DOM is *not* in the right state that I think it should be during my test scripts. So my scripts will complain about not finding an object or test-id etc and I have no idea why.

SOME of these findBy* will dump out the DOM to the term window when they fail. Some! And, worse, they truncate it waaaaay to early!!! I dont know about you, but my DOM sections can be very nested and I need to *see* the guts. So,

I think the “debug()” Jest API will print the baseelement but limited too small.  So, now, in my test logic, as I step through, fire events, etc, i will periodically call “prettyDOM()” BUT with a very large limit.  This alone has helped me tremendously!

prettyDOM(tt.router.baseElement, 100000)

(Keep in mind, your test scrip can: 

import {

 prettyDOM

} from “@testing-library/react”;

Last: FindBy*, GetBy*, etc…which to use???

I have my own little test-wrapper module that helps my test runtime. Often, I ask to load a component, or click/fire-event, and then want to “wait for things to show up”.  Sometimes I want to wait for their “text on screen”, sometimes “by their test-id”, etc.  

So I have a library function that basically says: Use this ‘test-by’ function, wait-for the first item in an array of items to be present, then verity the rest.

static async waitForItems(getBy_this, list) {

And for the “getBy_this” you can pass-in “getByText” or “getByTestId” OR (important!) “getByDisplayValue” (for forms/input using ‘defaultValue’ vs controlled).   But here’s a very important tip…multiple values.

If you use getByText or TestId etc, AND there are more-than-one-match, it will fail! NOT because it didn’t find what you asked, but because it found MORE! So you have to detect that and deal with it. I have. Maybe I’ll publish my test-layer code…

Leave a Comment

Your email address will not be published. Required fields are marked *