Forem: Code D' Ivoire

How to mock an imported Typescript class with Jest

Abou Kone — Thu, 02 Apr 2020 23:52:31 +0000

Sooner or later in your unit tests you will run into an issue where you need to import a class into your test and mock it, to keep up with good test hygiene. Jest offers a pretty good how to in their documentation on how to set it up for ES6 classes but if you try those instructions out of the box with Typescript, you will run into the type monster. This is a quick post to get it working for Typescript if you're using Jest. If you're an Angular developer and have not set up Jest yet, follow this great tutorial by Amadou Sall, the bonus is that you will also set up jest-preset-angular, which will help down the road.

SoundPlayer Class

Let's say this is your sound-player.ts file:


export class SoundPlayer {
  constructor() {
    this.foo = 'bar';
  }

  playSoundFile(fileName) {
    console.log('Playing sound file ' + fileName);
  }
}

Notice that this is not a default export. That's an important factor that if you follow the Jest documentation, their examples assumes that you're using default exports, which will matter later on in the mock.

SoundPlayer Mock

Now let's say you're writing a unit test for another class, let's say SoundPlayerConsumer and you want to mock SoundPlayer. If you don't have ts-jest installed, I highly recommend to add it to your Jest configuration now.

yarn add --dev ts-jest @types/jest

Like I mentioned earlier, if you're using jest-preset-angular, it already comes "bundled" with ts-jest.

With ts-jest in the bag, mocking a Typescript class with Jest is as easy as:

import { mocked } from 'ts-jest/utils';
import { SoundPlayer } from './sound-player';

jest.mock('./sound-player', () => {
  return {
    SoundPlayer: jest.fn().mockImplementation(() => {
      return {
        playSoundFile: () => {},
      };
    })
  };
});

describe('SoundPlayerConsumer', () => {
  const MockedSoundPlayer = mocked(SoundPlayer, true);

  beforeEach(() => {
   // Clears the record of calls to the mock constructor function and its methods
   MockedSoundPlayer.mockClear();

  });

  it('We can check if the consumer called the class constructor', () => {
    const soundPlayerConsumer = new SoundPlayerConsumer();
    expect(MockedSoundPlayer).toHaveBeenCalledTimes(1);
  });

}

It's pretty self explanatory but here are some clarification points:

Contrarily to the Jest documentation, since we're not using a default export, we have to reflect the namespace of the exported class module:

return {
    SoundPlayer: jest.fn().mockImplementation(() => {
      return {
        playSoundFile: () => {},
      };
    }

If this was a default module, we could have written it simply as:

  return jest.fn().mockImplementation(() => {
    return {playSoundFile: mockPlaySoundFile};
  });

If you're getting a “TypeError: ”X“.default is not a constructor.” when trying to run your tests, it's because you have not reflected the exported namespace properly.

The magic here happens because of the mocked method, which according to the documentation :

The mocked test helper provides typings on your mocked modules and even their deep methods, based on the typing of its source. It make use of the latest TypeScript features so you even have argument types completion in the IDE (as opposed to jest.MockInstance).

The first tell tale sign that your setup is not right would be getting an error of type error TS2339: Property 'mockClear' does not exist on type X X being the class you are trying to mock.

I hope this helps you write better unit tests.

Angular Testability: Dealing with Selenium or Protractor timeouts

Abou Kone — Wed, 01 Apr 2020 21:40:24 +0000

Running automated integration tests is a crucial element for any serious CI/CD pipeline and within our company, our QA uses Selenium for that purpose. Angular offers Protractor for that purpose, but to each artisan his tool, our Angular apps are just part of a suite that include non Angular apps and it's easier for the team to test them all using Selenium.

Anybody that has messed with Protractor knows that one of the early frustrations you will run into is knowing from the Selenium's perspective when the Angular page is done doing what it does and is ready to be tested. For novices that would mean any API calls you would be making to the backend to get data, any animation running on the page that as a user you typically wait for before knowing that yes, this page looks like it's ready for me to interact with. Early on our team ran into just that issue and time and resources being an issue, decided to use timers to wait for a reasonable time for the test to assume that the page is ready to interact with. That works most of the time but of course it's not the way you want to run a long term stable QA solution.

The Testability API

For the purpose of testability, Angular exposes the Testability API:

The Testability service provides testing hooks that can be accessed from the browser and by services such as Protractor. Each bootstrapped Angular application on the page will have an instance of Testability.

Plugging into that API is the way for your testing framework to know when your Angular app is ready to be tested. It uses NgZone to keep track of all outstanding operations currently running in your application and once they are all completed, marks your application as stable. The way that is done with most selenium scripts is to run a Javascript script from within Selenium that does one of the following:

Synchronously you can execute a Wait condition that waits for your script to return true like:

Java code
...

 wait.until(new ExpectedCondition<Boolean>() {
            public Boolean apply(WebDriver driver) {
                String angularScriptPath = "src/angular-script.js";
                String angularScript = null;
                try {
                    angularScript = SeleniumWebDriverTest.readFile(angularScriptPath);
                } catch (IOException e) {
                    e.printStackTrace();
                }
                Boolean angularPageLoaded = ((JavascriptExecutor) driver).executeScript(angularScript);

                return angularPageLoaded;
            }
        });

...

and your angular-script.js would look like

return window.getAllAngularTestabilities().findIndex(x=>!x.isStable()) === -1

Check out this well written article that explains how to wait for Angular page readiness using Selenium and gives a JSWaiter Java class that implements the correct approach for Angular > v5.

You can also go the async way and run an async script in Selenium that will provide a seleniumCallback callback function that your script will invoke when Angular is ready

let rootElement = window.getAllAngularRootElements()[0];
let testability = window.getAngularTestability(rootElement);
testability.whenStable(seleniumCallback);

The catch is that this is only half the story, because any async process that you have running in your Angular app needs to indeed be done before Angular thinks that all testabilities are done and ready.

If you have tried this above and it is still not working, it's more than likely because you have an async process running that prevents your app from ever attaining stability for test purposes. This is a particular true if you're using setTimeout or setInterval, let's say for example that as soon as the user logs in you launch a setInterval to determine when their authentication or session tokens expires. If you trigger that a setInterval as soon as your app boots up, you're toast in terms of testing if you don't take the proper measures as your app testability will never reach the stable point. That will more than likely mean a timeout if you're using Protractor or Selenium.

How to get stable

To attain stability for testing if you're using setTimeout or setInterval there are two things you can do:

Use ngZone.runOutsideAngular()

Use ngZone.runOutsideAngular if you're doing any work that does not require UI updates. If your work does require UI updates (where change detection is required), you can easily re-enter the Angular Zone by using ngZone.run. Check out this article for an in -depth explanation of ngZone and how it works with testability.

Delay starting any timers until you really need to

In my own case I was starting a timer as soon as the user logged in. I just delayed setting that timer until the Angular app is indeed ready for testing. This was a simple as delaying starting the timer in my authentication logic until Angular told testing was ready using a Testability on the Angular zone:

new Testability(ngZone).whenStable(()=>　{ 
        console.log("Now I am stable");
    　});

Check out this Stackblitz for an idea on how to do that:

With this simple change in the flow, the app reaches testing stability before the other processes can kick in.

One last thing that might help in debugging this issue for you, how would you know that you have incomplete async tasks still running? Lucky for you, this blitz will help you setup your app to log all running microtasks in your Angular zone. This will allow you to check on any process you might have overlooked that is keeping your app from stabilizing initially:

Also check out this Stackoverflow discussion for some more context on this issue and how to solve it.

A day in the life: how a frontend developer solves a "simple" bug

Abou Kone — Sun, 23 Feb 2020 20:26:24 +0000

I have been working lately with junior front end developers, as well as mentoring aspiring developers and one of the questions that they ask me is how to become a better/senior developer. That's a question that is hard for me to answer quantitatively but the one quality that I know about senior developers is their ability to solve problems, in a timely fashion. In this post I wanted to illustrate that aspect, but also to give an anecdotal insight into what a day might look like in the life of a front end developer, and the twists and turns that it can take to solve a seemingly simple problem.

The Bug

I had implemented a new report page for one of our applications, where the user can create a spreadsheet like report by setting a few parameters. I say spreadsheet like because although it visually looks like a spreadsheet to the user, I implemented it as a flexbox based grid of individual grids, due to other requirements that made it difficult to achieve with a regular table. So far so good, except that to maintain the table appearance, I really need pixel perfect coherence between the individual grids which after a little tweaking with padding and margins I achieved on Chrome on my Macbook. The code is deployed, everything looks good except for my colleagues running on Windows, they observed a slight shift one some of the columns, breaking the table illusion. To give you an idea, this is what they were observing:

Easy enough I told myself 8:30ish AM that morning, it's just another rendering issue, I just need to reproduce it and fix it.

Lesson 1: "It works on my machine" should never be a valid developer's answer to a bug. Unless you believe that other people at delusional, you should use it as a basis to start your investigation knowing that at least it works somewhere. It should never be from your perspective the end of it.

Reproducing the issue on Chrome/Mac

Like i said, my colleagues on Windows 10 were definitely seeing that bug so I first tried changing the resolution on my Chrome browser to see if it might be related to a responsiveness issue, no dice that way. Next I changed my focus to the operating system and thought that maybe the issue was related to a difference in the Chrome rendering depending on the OS.

Reproducing the issue on Chrome/Windows 10 with BrowserStack

Next then was trying it in Chrome on a Windows 10 instance of BrowserStack. After many tries, again no dice. Let's try something else. I remembered I had a IE11/Windows 10 VM lying around for my (non Chrome) Edge. By this time, with standup included, it's 12:00ish PM.

Reproducing the issue on Chrome/Windows 10 with VirtualBox

I fired up the VM and tried to reproduce the issue, still no luck. I further probe with my colleagues and it became clear that the issue was resolution related. Their laptop was running on a 1920x1280 resolution and they were easily able to reproduce. i spent the next hour or so trying to get VirtualBox to render my Windows 10 VM guest using that same resolution to no avail. Somewhere in my Googling somebody mentioned using Parallels, which I had already installed.

Reproducing the issue on Chrome/Windows 10 with Parallels

With Parallels fired up, I was quickly able to fire up a Windows 10 VM with the correct resolution, install Chrome, which led me to one of my favorite snark for my Windows colleagues

// Detect dark theme var iframe = document.getElementById('tweet-1230929236082425859-774'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1230929236082425859&theme=dark" }

and lo and behold on accessing our dev server, the bug was there as soon as the page loaded. After a quick debugging session, I found the culprit behind the rendering issue.

Lesson 2: Be good at accepting when it's time to fold. If you're going down one road and it's not working, learn to quickly re-assess and try something different that will get you closer to your goal.

The Problem

While defining one of the borders for a particular grid, I had used the following code:

border-top: dashed

On Chrome Mac, this translated actually to:

border-top: dashed 3px;

Basically creating a 3px dashed border by default. I naively assumed that this was the default border with in Chrome. I found that in Windows, leaving Chrome to make the decision actually rendered as:

border-top: dashed 1px;

So there was always a 2px difference between the grids. Easy enough, now that I knew the problem, I wanted to switch back to my local env to fix and test the issue. It's around 3:00PM.

Lesson 3: With CSS, be as specific as possible when creating your rules and don't assume.

The Fix

Here again, while trying to work on the fix, I ran into another snag. Our Angular app runs on port 4200, and our API on 8080, which means that even after setting Parallels to be able to access my Mac localhost from my Windows VM, I was still unable to launch the app because of CORS issues. There are many different ways of solving this issue, i quickly tried:

Editing my /etc/hosts
ngrok

but I decided to make use of the built-in Angular proxy configuration which we had previously used but discarded after enabling CORS on the API. What I thought would be a 1 minute affair turned into an hour when i realize the proxy configuration was not working!

The Angular Proxy

I was defining the different api proxy paths in proxy.conf.json as:

 "/api": {
    "target": "http://localhost:8080/api",
    "secure": false,
    "logLevel": "debug",
    "changeOrigin": true
  },

When the application was running, trying to hit for example /api/reports would proxy to http://localhost:8080/api instead of http://localhost:8080/api/reports. WTF? After re-reading the documentation many times, it finally jumped at me what I was doing wrong and the Angular/Webpack-dev-server people will correctly point out that ,y target was wrong, I should not add the context path in the target url but just the host. After changing the configuration to:

 "/api": {
    "target": "http://localhost:8080",
    "secure": false,
    "logLevel": "debug",
    "changeOrigin": true
  },

everything was peachy again and I was able to work and fix the issue properly. Psych! In the meantime, one of the Junior developers submitted a PR for which I had to do a code review, which lead to a video call to go over the code implication in depth since unbeknownst to the dev, his code as implemented would introduce a couple of regression bugs in the code. With that out of the way I was finally able to get back to the issue to fix and deploy, it's around 5:00PM now.

Lesson 4: Pay attention to details, especially syntax and spelling. That's why practices like pair programming and code reviews are important. Having a second set of eyes going over your code will help catch these little errors that we make that take too long for us to catch because we are used to our own code.

Summary

What looked like a simple visual CSS bug created a journey that involved of course Google, VirtualBox and Parallels Desktop VMs, Browserstack, Angular and some high level networking (etc/hosts). I've learned a few things during that process and here are some of the advice from that experience in that day that I would share with aspiring front end developers:

Whoever told you that as a front end developer, you would only be dealing with HTML, CSS and Javascript lied. As you have seen, producing applications require a lot more knowledge that usually, you can't teach directly. It's something that you pick up with experience.
As a developer, your number one skill to develop is your problem solving. As illustrated here, solving code issues is sometimes not a straightforward affair. You will have to solve problems within problems.
Take ownership of your work. You are ultimately responsible for the code you produce and it is your duty to ensure that it is of the highest quality.
Embrace the process. This is what makes our industry so fun but so frustrating at the same time. Things will not always run right, even if (you think) you're doing everything right. Things will break or malfunction, even with your best efforts and part of your job is to figure out how to get them working again.
For non-coders on the team, it's important to understand that things that look "simple" can turn out not to be so simple, either in implementation or in correcting when it comes to estimations.
For my non English speaking friends, up your English skills. Like i said, navigating those issues required a lot of Googling and I can't imagine how much slower I would have gone had I not been proficient in English. There is a lot of good information out there and the absolute majority of it is in English, so having a good grasp of the language definitely helps.

With hindsight now, I went back to BrowserStack and it looks like you can launch a VM with a particular resolution, which would have saved me a couple of hours maybe if I had paid attention. At the end of the day, I found the whole experience funny but not atypical, and I learned some things from it. This is why wanted to share it with others, especially, more junior developers dealing with impostor syndrome to show you that being senior does not mean being all knowing and perfect, it just means that you're gonna "mess up in style" and usually be able to recover from those mess-ups quicker. What about you, do you have any interesting bug or experience that you could share?

How to internationalize a Yup validation schema in a React, Formik and react-i18next app

Abou Kone — Thu, 13 Jun 2019 13:56:09 +0000

Internationalization of Yup validation schema with Formik and react-18next

Anybody that had to deal with internationalization (shortened as i18n) knows that it can be a real pain if not handled properly, but in the modern Javascript stack, there exists libraries that remove a lot of that pain and actually make it a breeze. One of these libraries is i18next. If you work with React, you can’t do better than its react-i18next port for the way it seamlessly exposes the i18next API using all of the major React constructs (Hooks, HOCs, Render Props and Components). Formik is form management library that promises to allow you to “build forms in React, without the tears” and I can say that indeed so far, my eyes have remained quite dry. Who says form also says validation, and Formik integrates easily with Yup, a JavaScript object schema validator and object parser. Yup supports localization, but you have to
provide it with a custom locale object, and I felt that the translation functionality should be single handedly handled by i18next. This article will explore how you can sync the translation of the validation errors in Yup when the user changes the selected page language.

The Bug

In the StackBlitz below, we have a basic setup of React, react-i18next, Formik and Yup. We display a form with a required email field defined in a Yup schema. This form can also be translated in French. To observe the bug in question in syncing the translation:

Click in the email field
Click outside
You should see a Email is required error.
Now click on the Francaislink.
Everything on the page changes to the French translation except for the validation error.

I suspect this happens because validation schema is initiated when the component renders with the language set to English initially, and on changing the language, the validation is not re-ran, causing the message to stay in English.

The Fix

Luckily the i18next exposes events, in particular the languageChanged event that we can listen to and update the validation so the validation message can be translated. I initially implemented in a global useEffect hook (that I will share later in this article) that listened for this event and re-ran the form validation , but this issue on Github had a more elegant solution, setting all field
with an error to be touched, which should trigger the field validation. The code in question is here:


    i18n.on('languageChanged', () => {
        Object.keys(errors).forEach(fieldName => {
            setFieldTouched(fieldName)
        })
    })

Here is a blitz of the working translation:

The errors object and setFieldTouched function here are the form.errors and form.setFieldTouched properties of the Formik form object passed in a prop. My requirements were different as I only wanted to show an error if the field had indeed been touched.

Use a hook

In my particular case, I was dealing not only with field level validation bugs, but I also had nested forms where the same was happening. I created a global hook that takes in a Formik form object and sets only the fields that have an error as touched. Here is the code:

This way if the user had previously interacted with the field and gotten a validation error, the translation will re-render the form only with the existing errors translated. You can adjust depending on your business requirements.

WithTranslateFormErrors HOC

I’ve created an HOC that you can add to your Formik form that will set this up for you. The code is pretty simple:

And you would include it in your Formik form like this:

You don’t need to use the HOC if you’re rendering your Formik form as a
component. In that case, you can just use the useTranslateFormErrors hook on its own in your render function.

This hook and HOC are available as part of the react-i18next-helpers library I recently released.