5 Tips for Writing Great Javascript Unit Tests

Unit tests are a great way to get quick feedback after any code change — if you know how to use and write them well. The key factor to writing high-quality unit tests is to make them maintainable, readable and reliable.

Stick around — we’re about to review 5 important tips for writing unit tests in javascript.

It’s very easy. Don’t worry :)


Names

Your test name should be explicit, descriptive and concise. If your test fails, your first indication of what may have gone wrong will be found in the test name.

For example:

👎 The description does NOT describe the intended action and the expected result
👍 The description DOES describe the intended action and the expected result

Usually, in the “describe” argument we put the description of the unit of work. In the “it” argument we put the above pattern ‘should [expected behavior] when [scenario/context]’.

One Concern in One Test

Each test should evaluate one and only issue. With each test responsible for only one concern of the bigger picture, it can reveal exactly why a given scenario fails — no other issues are complicating the cause-and-effect. Adopt the practice of putting one “expect” in each “it”.

👎 The ‘it’ contains two ‘expect’ terms. That means, that this test evaluates two concerns instead of one: an undefined type and a boolean type.
👍 In this example, each test evaluates for only one concern. The first test checks that the isUndefined function works well with the undefined type, and the second test checks that the function works well with boolean type.

How Does Your Code Behave?

See the macro, not the micro. Test the behavior of your code and not the internal implementation of it. Changing the code’s internal implementation will not result in the unit test outcomes. That said, in the event that your test fails, consider debugging the function to help you determine where the test failed.

👎
👍

One Initialization

Any initialization should be written in the shared setup beforeEach. Otherwise, you may be rewriting the same code several times, which is the time consuming, risks the introduction of errors, and is fundamentally unnecessary. Use the central initialization place, called beforeEach. It’s an efficient way to create that very clean, simple, short and easy to read.

👎
👍

Mock External Resources

Usually, the code we write is designed to make changes in the “real world” — changing some reality in our external resources. When we run tests, the last thing we want to do is modify those external resources. We therefore need to make sure that our unit tests are “stateless,” so that we can run them whenever we need to, without cleaning our development environment for test conditions.

An additional benefit of using a mock environment is that tests run there much faster than they would via the external resources that are already currently functioning in real time.

Avoid Logic in Your Tests

The logic of code inherently requires a premise, a condition, and a conclusion. If a test were to include logic, therefore, it would not be a “one-concern” test. Instead, when you find yourself writing logic into a test, divide it into smaller tests of only one concern each. Remember, when you test only one concern per test, you are able to evaluate your code precisely.

Furthermore, you simply don’t want to write bugs into your tests, , and you’re at risk of that when you incorporate logic.

Similarly, try to avoid writing loops, conditions and switch cases.

References

Js-Unit-Testing-Guide Github repository

Writing great unit tests best and worst practices article


Conclusion

Unit Tests usually provide the first valuable feedback after discovering broken code. Not only are they significant for the quality of the deployments and the product itself, but also for your productivity as a Javascript developer.

I recommend that you make a checklist of the tips in this article, together with any others you may have come across and use it to make sure your tests will provide you with the information you need, in the event you ever need it. Be in touch if you have points you’d like to add, comments you want to bring attention, or new ideas that we should include.

If you liked this, click the💚 below so other people will see this here on Medium.