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.
Perform End to End Testing Over a Production-Like Environment
We should run our end to end tests over a production-like environment so that we know that our code will probably work in the production environment.
We can create an isolated environment with Docker-compose with one command.
It will create a Dockerized environment with everything we need with one command.
We can also use something like AWS Local to stub AWS services.
Parallelize Test Execution
We should run tests in parallel so that we can run more tests in less time.
There’re extensions for test frameworks like Jest and Mocha that’ll let us run tests in parallel.
Since we’re supposed to keep tests independent of each other, we should be able to do this easily.
We can run tests with multiple processes to speed up feedback time a lot.
Stay Away from Legal Issues
We should check for licenses so that we won’t be violating them.
Otherwise, if someone catches us, then we’ll run into problems.
It’s easy to use things accidentally without looking at the license.
We can use the license-check package to check our code.
To install it, we run:
npm install -g license-checker
Then we check the licenses of our dependencies by running:
license-checker --summary --failOn BSD
Inspect for Vulnerable Dependencies
We should inspect for vulnerable dependencies so that attackers can’t attack our apps.
To do this, we run npm audit or use snyk to check for vulnerable dependencies automatically.
Automate Dependency Updates
We can automate the update of our dependencies so that we won’t have to do everything ourselves.
Tools like ncu let us manage dependencies automatically.
There’s also the npm outdated to check for outdated dependencies.
We can run that in our CI to stop and builds that have obsolete dependencies.
Also, we can check each pull request for updated dependencies.
Native Docker Support
Docker makes devops easier, so we can use it to deploy and run our apps instead.
Fail Early
We should run our fastest tests first so that we can run quick inspections of our app.
And if there’re any failures, it’ll occur early.
Check Build Artifacts
Build artifacts like test and coverage reports, logs, etc. should be easy to find so we don’t have to waste time looking for them.
Create Multiple Pipelines
Pipelines are useful for automating our work.
We can configure a job for feature branch commits and different one for master PR.
But we can reuse the logic between them so that we don’t have to do the same work twice.
No Secrets
We shouldn’t have secrets in our jobs.
They should be retrieved from a secrets store from the job configuration.
Bump Version in Release Builds
The version in release builds should be bumped so that we can distinguish them.
Conclusion
There’re other things we can automate so that we can do less work.
