There are several types of testing methodologies. You can have tests to measure performance by stressing your application with specific actions and checking whether it achieves the expected minimum results. Those are important, but not at this stage. We should focus on other kinds of tests.

Our goal is to have a test suite that ensures our code behaves as we designed it. To ensure that, we must have:

• Unit tests, to check individual code units, such as some functions
• Integration tests, to check whether external actions produce the expected results

Using these two types of test, and having a full code coverage, we'll be able to develop new features and run regression tests, which is just a fancy way of saying that our test suite still passes, and our new code does not break (there's no regression).

You may see these regression tests as and when you run the test suite on your laptop and the results are OK, and then you commit your code to GitHub, for example, and Travis runs the same test suite on different environments to see if nothing breaks. If you're pushing to a pull request on GitHub, you'll be unable to merge your changes unless every test result passes.

To achieve full test coverage, you'll necessarily have test cases in the same language as the one used to develop the application, which in our case is Node.js. It's not mandatory, but it simplifies a lot of the tools used to run the test cases use the same language, as this creates a friendlier environment for other developers.

When using open source modules, it's not uncommon for others to find issues and try to fix them. Having test frameworks that involve installing third-party software will lower the interest in helping to fix them. On the other hand, if the user just needs to clone the repository, fix and run the tests, that will be a much more enjoyable experience.