DEV Community: Rafael

Testing JavaScript with Jest - Unit Testing

Rafael — Wed, 11 Aug 2021 22:52:16 +0000

Introduction

Over the last couple of weeks I've been immersing myself in the world of testing my JavaScript and Python projects, and OH BOY. It's so much fun that I can't believe I didn't start learning it sooner.

I've come to realize that testing our code is essential for writing maintainable, reusable, and modular code. And it also makes it easy for any contributors, colleagues, and in general any people we work with to be almost absolutely sure their new coolAndGreatFunction420() doesn't break our entire project.

This article will cover the very basics of how testing works, what it's used for, and how to implement it in our Node.js apps using jest.

What is testing?

Testing code is the process of making sure our software behaves the way we intend it to. Testing our code can help us feel more comfortable with our final product.

For example, if we have a program which purpose is to add 2 + 2 and return 4, we'd like to make sure it does exactly that. We don't want it to return 5, or 1, or "cuatro", we want it to return 4. Tests enable us to make sure this program behaves as expected every time we run it.

Testing software comes in different shapes and sizes. For example, we could test the program mentioned above by simply using it the way a user would. We could launch a terminal, or a browser, or any kind of GUI, and run the program several times, making sure it always returns the expected value. The fun kind of testing, however, is automated testing.

Automated testing is code that tests code. Awesome, right? This can be achieved by using frameworks that enable us to write testing code.

Even though automated testing is the focus of this article, I think it's still important to manually test our programs. This way we make sure our end-users have the best experience possible with our products.

It's important to note that testing -no matter how in-depth or complex our tests are- can't ensure bug-free code. However, I do believe that testing improves code quality and makes better products in the end.

Types of tests

Before we get into practical examples, we should know the common types of testing. These are not the only types that exist, but the most popular ones in the world of JavaScript.

Unit tests

Unit testing covers blocks of code, making sure they work the way the are intended to work. A unit could be a function, a class, or an entire module. Personally, I recommend unit tests to be limited to functions, just because I try to test the smallest parts of my code first, but there is no real rule for this. We can have two types of units:

Isolated or solitary units: units that have no other dependencies, and which behavior and/or output depend only of the block contained within it.
Sociable units: these are units that have dependencies. Their execution and optional output depends on other units. When testing, this means that we gotta make sure their dependencies work as expected before testing them.

// This is an isolated unit
function myNameIs(nameString) {
    return `Will the real ${nameString} please stand up`;
};

// This is a sociable unit, because it depends on other units
function pleaseStandUp() {
    return myNameIs("Slim Shady") + "please stand up, please stand up";
};

Integration tests

Just because our unit tests pass doesn't mean we have a functioning and complete application. Once we have made sure that our units are properly tested and work by themselves, we test them together in the same way they are used in our software. This is integration testing. Putting these units and testing them together ensures that our functions, classes, and modules play well with each other.

End to end tests (E2E)

End to end testing (E2E) takes our application for a ride from beginning to end. By this, I mean that this type of testing focuses on the user's experience whe using our software.

Remember how I said that manual testing is important, even when we have automated tests set up? Well, E2E testing is basically automated manual testing (try to explain that to a non-developer). These tests take place in the browser typically in a headless browser, although they can be run in browsers with a GUI. Through our test, we try to replicate as much as possible a user's interactions with our site, and make sure the output is what we expect.

In addition to replicating a user's navigational flow through the website, I actually also like to try to break things in these types of tests, as if I were a user typing and clicking madly through the site.

Unit testing with Jest

Jest is a Facebook Open Source product that enables us to write and run tests in pretty much any kind of JavaScript framework we prefer.

📖 NOTE

I know, I also don't love the fact that Jest -and React, for that matter- are Facebook products. However, I gotta admit that they are good products and Facebook is a topic for another post.

To install and use Jest in our project, we can run:

$ npm i -D jest

Then we can add a testing script to our package.json:

"scripts": {
    "test": "jest"
}

Whenever Jest is run, it'll automatically look for and run files that end in .test.js, .spec.js or any .js files that are inside of the __tests__ directory.

Now, let's go ahead and write the unit that we want to test. And don't worry, these may look simple, but they are actual functions that I've had to use in real-life projects.

// helpers.js
function isNumber(possibleNumber) {
    return typeof possibleNumber === "number";
};

module.exports = isNumber;

There we go, a very simple function that shouldn't be hard to test... right? Let's try writing our first test. For this example, let's assume the test file is in the same directory as the helpers.js module.

// helpers.test.js
const isNumber = require("./helpers");

test("should return true if type of object is a number", () => {
    expect(isNumber(5)).toBe(true);
});

That is what a basic jest file looks like. We import the module/class/function we want to test, we specify some description for what we expect the test result to be, and then we actually tell Jest what we think the function result will be. Let's break it down a bit.

test() is a Jest function that defines a single test to be run. You can have as many test statements in a single file as you like. It takes two required arguments and an optional third one. The first argument is the test name. It's customary to use it as a clear description of what is being tested. The second argument is a function where the body of our test lives. This is where we tell Jest what our expectations from the test are. In this case, we expect the return value from isNumber(5) to be true. The third argument is an optional timeout value in milliseconds. Since tests are usually really fast, we don't expect any singular test to take longer than 5 seconds, which is the default timeout value.
expect() is the function we use to actually test our expectations. We use expect along with "matcher" functions which asserts certain conditions about a value. In this test we're using the toBe() matcher, which compares actual values with our expectations. There's a lot of matchers, and I'll only cover a few here, but you can read more about them in the Jest matchers section of their documentation.

📖 NOTE

You can have as many expect() statements in a test as you like, there's no limit! It's recommended you use only as many as it makes sense, since you can also write as many test() statements as you like, and it becomes more readable to organize your expect() statements with their respective test cases.

Now that we have written our first test, we can run npm run test and see the magic happen:

$ npm run test

> testing-javascript-with-jest@1.0.0 test
> jest

 PASS  ./helpers.test.js
  ✓ should return true if type of object is a number (2 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.279 s, estimated 1 s
Ran all test suites.

📖 NOTE

"Test Suites" refers to the number of files jest ran, while "Tests" refers to all the test() statements found within those files.

Like I said before, Jest automatically looks for and runs all test files in our source code, and it does this really fast. Congratulations on writing your first unit test!

Let's write a couple more tests for this function, just so we make sure we cover as many use cases as we can.

// helpers.test.js
const isNumber = require("./helpers");

test("should return true if type of object is a number", () => {
    expect(isNumber(0)).toBe(true);
    expect(isNumber(5)).toBe(true);
    expect(isNumber(+"5")).toBe(true);
});

test("should return false if type of object is not a number", () => {
    expect(isNumber(null)).toBe(false);
    expect(isNumber("number")).toBe(false);
    expect(isNumber(undefined)).toBe(false);
});

We run npm run test again and...

$ npm run test
...

 PASS  ./helpers.test.js
  ✓ should return true if type of object is a number (2 ms)
  ✓ should return false if type of object is not a number

...

Great! Our function seems to be working as intended.

Grouping tests under `describe()`

We could get away with just writing our tests at the top level like the one we just did. However, we can see that despite seeing our test descriptions and their results, we can't tell by the terminal output what unit we're testing. Let's illustrate this better by writing a second function in helpers.js and adding its respective tests to helpers.test.js.

// helpers.js
...

function isObject(possibleObject) {
    return typeof possibleObject === "object";
};

module.exports = { isNumber, isObject };

// helpers.test.js
const { isNumber, isObject } = require("./helpers");
...

test('should return true if type of object is "object"', () => {
    expect(isObject({})).toBe(true);
    expect(isObject([])).toBe(true);
});

test('should return false if type of object is not "object"', () => {
    expect(isObject(5)).toBe(false);
    expect(isObject("object")).toBe(false);
});

We run npm run test again and we get the expected (ha, get it?) result:

$ npm run test

> testing-javascript-with-jest@1.0.0 test
> jest

 PASS  ./helpers.test.js
  ✓ should return true if type of object is a number (1 ms)
  ✓ should return false if type of object is not a number (1 ms)
  ✓ should return true if type of object is "object" (1 ms)
  ✓ should return false if type of object is not "object" (1 ms)

Test Suites: 1 passed, 1 total
Tests:       4 passed, 4 total
Snapshots:   0 total
Time:        0.204 s, estimated 1 s
Ran all test suites.

Like I said before, while these results are great and we got all the green checkmarks, they're not the most readable, and we don't know which test belongs to what unit. There's a better way to organize our tests so that the output to the terminal is cleaner and easier to read.

By using describe(), we can group our tests together under a single block, and therefore, under the same scope -which will become useful later-. To implement the describe() function on our existing tests, all we gotta do is wrap describe() statements around a related group of test() statements.

// helpers.test.js
...

describe("isNumber", () => {
    test("should return true if type of object is a number", () => {
        expect(isNumber(0)).toBe(true);
        expect(isNumber(5)).toBe(true);
        expect(isNumber(+"5")).toBe(true);
    });

    test("should return false if type of object is not a number", () => {
        expect(isNumber(null)).toBe(false);
        expect(isNumber("number")).toBe(false);
        expect(isNumber(undefined)).toBe(false);
    });
});

describe("isObject", () => {
    test('should return true if type of object is "object"', () => {
        expect(isObject({})).toBe(true);
        expect(isObject([])).toBe(true);
    });

    test('should return false if type of object is not "object"', () => {
        expect(isObject(5)).toBe(false);
        expect(isObject("object")).toBe(false);
    });
});

This time, when we run npm run test, we'll see groups of tests organized under the same name.

$ npm run test
...

 PASS  ./helpers.test.js
  isNumber
    ✓ should return true if type of object is a number (2 ms)
    ✓ should return false if type of object is not a number (1 ms)
  isObject
    ✓ should return true if type of object is "object" (1 ms)
    ✓ should return false if type of object is not "object" (1 ms)

Both the terminal output and the written code become much more readable when grouping tests together, and for reasons that will become important in future articles, it also groups related tests under the same scope.

Running multiple test cases using Jest Each

As of Jest version 23, we've been able to use the each method on both the test and describe functions. each allows us to run the same test multiple times using values defined in a "table column". The table can be both array types and template literals using Spock Data Tables.

We can simplify our tests with multiple expect statements that contain different values like so:

//helpers.test.js
...

describe("isNumber", () => {
    // Instead of this:
    // test("should return true if type of object is a number", () => {
    //     expect(isNumber(0)).toBe(true);
    //     expect(isNumber(5)).toBe(true);
    //     expect(isNumber(+"5")).toBe(true);
    // });


    // We use this:
    const numbers = [0, 5, +"5"];
    test.each(numbers)("should return true since type of %j is a number", 
        numberToTest => {
            expect(isNumber(numberToTest)).toBe(true);
        });

It's a weird syntax, I know, but it makes it so much easier to test a large number of tests with fewer lines. In this case, we can just keep adding values to the numbers array and keep checking to see if they all return true without adding extra expect() statements.

📖 NOTE

%j is a printf formatting specifier. When we run jest, each test will have a unique name with its specific value injected in the string by the parameters passed into it by the table argument.

Let's do this for all our tests:

// helpers.test.js
...

describe("isNumber", () => {
    const numbers = [0, 5, +"5"];
    const notNumbers = [null, "number", undefined];

    test.each(numbers)('should return true since type of %j is "number"',
        possibleNumber => {
            expect(isNumber(possibleNumber)).toBe(true);
        });

    test.each(notNumbers)('should return false since type of %j is not "number"',
        possibleNumber => {
            expect(isNumber(possibleNumber)).toBe(false);
        });
});

describe("isObject", () => {
    const objects = [{}, []];
    const notObjects = [5, "object"];

    test.each(objects)('should return true since type of %j is "object"',
        possibleObject => {
            expect(isObject(possibleObject)).toBe(true);
            expect(isObject(possibleObject)).toBe(true);
        });

    test.each(notObjects)('should return false since type of %j is not "object"',
        possibleObject => {
            expect(isObject(possibleObject)).toBe(false);
            expect(isObject(possibleObject)).toBe(false);
        });
});

Now not only do we save unnecessary lines of code, but our tests all have unique names when prined to the terminal:

$ npm run test
...

 PASS  ./helpers.test.js
  isNumber
    ✓ should return true since type of 0 is "number" (1 ms)
    ✓ should return true since type of 5 is "number"
    ✓ should return true since type of 5 is "number"
    ✓ should return false since type of null is not "number" (1 ms)
    ✓ should return false since type of "number" is not "number"
    ✓ should return false since type of undefined is not "number"
  isObject
    ✓ should return true since type of {} is "object"
    ✓ should return true since type of [] is "object"
    ✓ should return false since type of 5 is not "object"
    ✓ should return false since type of "object" is not "object"

...

Summary

This is an introductory article, and as such, we learnt the very basics of what testing is, the most common types of testing in JavaScript, and how to do test our units using the testing framework Jest. We know now that to test our code we use the test() and expect() functions together. We also know that we can group tests that share similar logic under the same scope by using the describe() function, and we can reuse the same test under different test cases with the each method.

Thank you for reading, and see you next time!

📖 NOTE

This post was first published over at my website, go check it out if you wanna read more content like this.

Creating a weather app with Reactjs - Part 3

Rafael — Fri, 05 Feb 2021 00:25:07 +0000

Using our data

Alright! Now we have visible data that we can work with. If we go to our DevTools => Network tab, and we look for our fetch calls (one starts with "onecall" and the other one with "json?latlng", we can see what the response looks like. That's our data!
For Google Map's Geolocation API, we can see that they give us a lot of information. Which is good, but we don't really need all of that for this app. So, since I only really care about the city's name and the state's "short name" (i.e. California = CA), we can refactor our fetchData function's final lines like so:

Displaying our data

Great! Now our data is more managable. Now, let's create a simple section that displays current temperature, humidity, wind speed, city name and the state's short name.

Awesome! Now we can see the info on the page. We have to add a couple checks before trying to display the info, since it takes a bit for our app to get the data responses. This way, we won't get errors when we first render our app. These checks will also account for the case in which the user denies location access. So, whatever we put in that last part of the tertiary statement will display in case of any errors.

Great, we can see our data, but it's kind of ugly, isn't it? Let's fix that.

Styling using CSS modules

To use CSS modules in React, we'll create a new directory in our /src folder called /styles. Here, we'll have our stylesheets for all our React components (granted, some people prefer to have their css modules in the same directory as the component, but for this case I think this works fine). Let's also create a folder called /components, which we'll populate soon enough.

Before we start using css modules, let's convert our displayed data into it's own component, this will keep our App.js file cleaner and our files easier to handle. So, inside of /components, create a file named "CurrentData.js". Inside our /styles directory, create two css module files: one for App.js, and another for CurrentData.js. The App.module.css file will be our global stylesheet, where we'll reset the margins, define a font for the entire app, define css variables, etc. This is what those files contain.

App.js return statement

CurrentData.js, inside the /components dir

CurrentData.module.css, inside the /styles dir

App.module.css, inside the /styles dir

Our webpage in its current state!

Now we're coding! Don't worry, it looks like a lot but it really isn't. Also, I know the app isn't the most beautifully designed out there, but it serves its teaching purposes.

So, we separated the extense code into the CurrentData component (I called it that because we'll implement daily forecast later). In this component we make use of the data that we retrieved before, and we display it to the user. The unixToDate() function lets us convert the unix timestamp that we get from the One Call API into readable human time format. And that's it! Our app works! I'll be adding a couple more components over the next posts in the series, but this is the skeleton of it. You've made a weather app that works!

Creating a weather app with Reactjs - Part 2

Rafael — Wed, 03 Feb 2021 18:46:38 +0000

Fetching and using data.

Now that we have the user's coordinates, we can make a fetch call to the Open Wather Map's One Call API; which we can use to get very useful data, like:

Current weather
Hourly forecast for 48 hours
Daily forecast for 7 days
And more...

First things first. You'll need to create an account with them, which is free, and generate an API key for the One Call API, which is also free!
Once you do that, you should have an API key that looks something like this: "jadi1923mdas012jda...". Should be around 32 characters long. Now we're ready to implement our fetch call!

If we take a look at the One Call API Documentation, we'll see that to make an API call, we use an address like this:
"https://api.openweathermap.org/data/2.5/onecall?lat={lat}&lon={lon}&exclude={part}&appid={APIKey}".

The exclude parameter lets you, well... exclude weather data from the API response. For this app, I don't really care about the minutely or alerts parts of the data, so I'm gonna exclude those like this: "...&exclude=minutely,alerts...".

Since we also want to display the name of the city, we're gonna use Google's Reverse Geocoding API, which takes geographical coordinates, and returns an array of data about those coordinates. To access this API you again need to have a google account and generate an API Key, which is free. This is a process that unfortunately falls out of the scope of this series, but you can learn how to do it here. The reverse geocoding API url looks like this: "https://maps.googleapis.com/maps/api/geocode/json?latlng={lat},{long}&key={APIKey}"
Once you have both your keys, it's finally time to code!

Important

If you're using git/GitHub, it's important that you don't put sensitive information out there, like your API Keys. To work around this, put your keys in a separate .js file that you can access from your other files. Then, add this file to .gitignore. This way, no one but you should be able to see your keys.

Since we're gonna need all of this data at initial render, we'll do our fetch calls inside a useEffect() hook. We'll use an additional one to the one we already have, since they do different things. It looks like this:

As you can see, all we're doing is requesting data from both APIs. To prevent errors, we check first to see if the currentLocation object contains a latitude key. If it does, we'll run our functions. At the end, we tell react to run this hook everytime our currentLocation state updates. If you go to your React page now, and look at the console, you'll see two objects with the data that we requested. Good job!

Since we're using very similar functions both times, we should refactor this into a single function, and save ourselves some space.

A bit cleaner, huh?

That data is not useful to us in the console tho, we should store it in state so we can display it. Let's use two new useState() hooks for this.

And instead of displaying the data to the console, let's set it to these new state variables inside our fetchData function.

Done! Our data is now saved in state and we can access it later whenever we need it.

Creating a weather app with Reactjs - Part 1

Rafael — Wed, 03 Feb 2021 03:09:32 +0000

Introduction

Hello! In this series, I'll show you how I went about creating a weather forecast app entirely with Reactjs. The app uses React Hooks, API calls from OpenWeatherMap & Google Geocoding Services, and some CSS modules to make it all responsive (and look nice too, of course). Let's begin!

Pre-requisites

Node >= 8.10
npm >= 5.6
A text editor (VSCode recommended).
Some previous knowledge of Reactjs and React Hooks.
Some familiarity with using a command-line tool.
Usage of git/github is optional but recommended.

Starting out

1. Creating the React folder

To begin, open up a new terminal and initialize a new react-app in a directory called react-weather with the create-react-app command:

npx create-react-app react-weather

This will create a template Reactjs app that we can modify to make it our own.

2. Cleaning up our template

We won't use all files or sections of code created by the template, so let's take some time to clean up our workspace. We can go ahead and delete all of these files:

README.md
All files in the /src directory
All files in the /public directory but index.html, manifest.json and robots.txt
We can delete all the commented lines in index.html

3. Create initial component

Now that our src folder is empty, nothing will be rendered to the webpage if we were to run our app. To create our first component, and see it in action, we're gonna need two files: index.js and App.js. Each one will look like this for now:

index.js

App.js

Now, we can finally start creating our weather forecast app!

Working with hooks

Since this is a weather forecast app, I'd like to give the user their initial location's forecast, and after that, they can choose to look for a different city's data. To do that, we'll use the useEffect() hook, the useState() hook and the getCurrentPosition() function from the Geolocation API.

So, when the user launches the app, we want to get their current geographical coordinates and store them in state as an object. This is what that looks like:

Woah! Where did all that code come from? Let me explain.

useState()

The useState() hook sets state for a React component. It returns two values that we can get by declaring an array. First, a default value for the state variable that we want to set (an empty object in this case). Second, a function that we can call later to set the value of this state variable.

useEffect()

useEffect() is a tricky but powerful hook. It runs after initial render and also after every update. By specifying an empty array as a second argument, we tell this hook to only run on initial render. If we populate that array with one or more state variables, the hook will run after any of those variables changes.
So, this hook will run as the page renders, it will ask the user for permission to access their location, and will save that location data in state.

Now, as soon as the app launches, it'll ask the user for their location. If the user allows geolocation, we'll store their coordinates as an object in state. We'll handle the case in which the user blocks location in the future, for now, we'll assume that users always allow us to know their current location.

You can see that we have a button for displaying the geological information to the devtools console. Try it!

DEV Community: Rafael

Testing JavaScript with Jest - Unit Testing

Introduction

What is testing?

Types of tests

Unit tests

Integration tests

End to end tests (E2E)

Unit testing with Jest

Grouping tests under describe()

Running multiple test cases using Jest Each

Summary

Creating a weather app with Reactjs - Part 3

Using our data

Displaying our data

Styling using CSS modules

Creating a weather app with Reactjs - Part 2

Fetching and using data.

Important

Creating a weather app with Reactjs - Part 1

Introduction

Pre-requisites

Starting out

1. Creating the React folder

2. Cleaning up our template

3. Create initial component

Working with hooks

useState()

useEffect()

Grouping tests under `describe()`