Objectives ~ testing nodejs applications
Building, testing, deploying, and maintaining large-scale applications is challenging in many ways. It takes discipline, structure, and rock-solid processes to succeed with production-ready nodejs applications. This document put together a collection of ideas and tribulations from a personal perspective so that you can avoid some mistakes and succeed with your project.
In this article we will talk about:
- Avoiding integration test trap
- Mocking strategically or applying code re-usability to mocks
- Achieve a healthy test coverage
Even though this blog post was designed to offer complementary materials to those who bought my Testing
nodejsApplications book, the content can help any software developer to tuneup working environment. You use this link to buy the book.
Why
There is a lot of discussion around Unit testing. Developers don't like testing, only the testing approach differs from one person to another, from one system to the next one. It is also worth highlighting that some, if not the majority, skip TDD's way of doing business for alternatives. One thing is clear: You cannot guarantee the sanity of a piece of code unless it is tested. The “HOW” may be the problem we have to figure out and fix. In other words, should a test be carried out before or after writing the code?
Pro: Tests(Unit tests)
- Increases confidence when releasing new versions.
- Increases confidence when changing the code, such as during refactoring exercises.
- Increase overall code health, and reduces bug count
- Helps new developers to the project better understand the code
Cons:
- Takes time to write, refactor and maintain
- Increases codebase learning curve
What
There is a consensus that every feature should be tested before landing in a production environment. Since tests tend to be repetitive, and time-consuming, it makes sense to automate the majority of the tests, if not all. Automation makes it feasible to run regression tests on quite a large codebase and tends to be more accurate and effective than manually testing alone.
Layers that require particular attention while testing are:
- Unit test controllers
- Unit test business logic(services) and domain (models)
- Utility library
- Server start/stop/restart and anything in between those states
- Testing routes(integration testing)
- Testing secured routes
Questions we should keep in our mind while testing is: How to create good test cases? (Case > Feature > Expectations ) and How to unit test controllers, and avoid test to be integration tests
The beauty of having nodejs, or JavaScript in general, is that to some extent, some test cases can be reusable for back-end and for front-end code as well. Like any other component/module, unit test code should be refactored for better structure, readability than the rest of the codebase.
Choosing Testing frameworks
For those who bought in the idea of having a TDD way of doing business, here are a couple of things to consider when choosing a testing framework:
- Learning curve
- How easy to integrate into project/existing testing frameworks
- How long does it take to debug testing code
- How good is the documentation
- How good is the community backing the testing framework, and how well the library happens to be maintained
- How test doubles (Spies, Mocking, Coverage reports, etc) work within the framework. Third-party test doubles tend to beat framework native test doubles.
Conclusion
In this article, we revisited high-level objectives when testing a nodejs application deployable at scale. There are additional complimentary materials in the “Testing nodejs applications” book that dives deeper into integration testing trap and how to avoid it, how to achieve a healthy code coverage without breaking the piggy bank, as well as some thoughts on mocking strategically.