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:
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”.
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
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.
