JavaScript Unit Test Best Practices — Organization

John Au-Yeung
Aug 26 · 3 min read
Image for post
Image for post
Photo by JESHOOTS.COM on Unsplash

Unit tests are very useful for checking how our app is working.

Otherwise, we run into all kinds of issues later on.

In this article, we’ll look at some best practices we should follow when writing JavaScript unit tests.

Design for Lean Testing

Test code should be simple, short, and abstraction free.

They should also be lean.

The less complexity our test code has, the better it is.

We just do something and check the results in our tests.

Include 3 Parts in Each Test Name

We should have 3 parts in each test name.

The first part is the module being tested.

The 2nd is the circumstance that we’re testing the code in.

The expected result is what we’re checking for in our test.

This way, we can tell what’s being tested and find out what to fix if it fails.

For example, we write:

Structure Tests by the AAA pattern

We should structure our tests with the AAA pattern.

The 3 A’s stands for Arrange, Act, and Assert.

Arrange means the setup code is added to let us do the test.

Act is doing the test.

Assert is checking the result after doing what we have.

So if we have:

We arrange with the first line of the test.

Act is the call for the login function.

Assert is the expect call.

Describe Expectations in a Product Language

We should describe tests in human-like language.

The behavior should be described so that we can understand what the test is doing.

The expect or should should be readable by humans.

For instance, we write:

The strings we pass into describe and it explains the scenarios and tests clearly.

Test Only Public Methods

We should only test public methods so that we aren’t testing implementation.

We don’t care about the implementation of our tests.

All we care about is the results.

We should look at them when we don’t get the expected results from the tests.

This is known as behavioral testing.

We’re testing behavior and nothing else.

For example, we shouldn’t write code like:

We shouldn’t test private variables which can change any time.

Avoid Mocks in Favor of Stubs and Spies

We got to stub some dependencies since we can’t do everything in our tests as we do in a real environment.

Our tests shouldn’t depend on anything outside and they should be isolated.

Therefore, we stub all the dependencies that commit side effects so that we can just test what we want to test in isolation.

We just stub any network request code.

And we watch what we want to check is called with spies.

For instance, instead of mocking a database like:

We spy on the function we check it’s called by writing:

We spied on the Emailer constructor’s sendEmail method to check if it’s called after we called UserService instance’s delete method.

We avoid mock any server-side interactions with the spies approach.

Image for post
Image for post
Photo by Scott Graham on Unsplash


We should test with stubs and spies.

The tests should be lean and divide our tests into 3 parts.

JavaScript In Plain English

Did you know that we have three publications and a YouTube channel? Find links to everything at!

JavaScript In Plain English

New JavaScript + Web Development articles every day.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store