The name is an homage to the legendary first ever testing book ‘The Art Of Software Testing’ by Glenford Myers’
Note: Work in progress, to be released in 01/2021
This repo shows the immense power of narrow integration tests, also known as ‘component test’, including examples and how to set them up properly. This might make a huge impact on your testing effort and success 🚀
The testing world is moving from pyramids to diamonds, more emphasis is being put on integration tests and for good reasons. Here to put reasons to move toward more integration tests
This repo provides the following benefits and assets:
Some details on the example applications and link to the folder
✅ Do: For proper startup and teardown, the app entry point (e.g. webserver start code) must expose for the testing a start and stop methods that will initialize and teardown all resources. The tests will use these methods to initialize the app (e.g. API, MQ) and clean-up when done
👀 Alternatives: The application under test can avoid opening connections and delegate this to the test, however this will make a change between production and test code. Alternativelly, one can just let the test runner kill the resources but then with frequent testing many connections will leak and might choke the machine
✏ Code Examples
✅ Do: Let the web server randomize a port in testing to allow multiple processes and instances. Specifying a specific port in testing will prevent two testing processes from running at the same time. In production, specify a specific port in an environment variable and use it. In testing, specify no port.
👀 Alternatives: You may initialize one webserver in a dedicated processes, but then the tests and API under test won’t be on the same process and many features like coverage and test doubles won’t be feasible
✏ Code Examples
✅ Do: All the databases, message queues and infrastructure that is being used by the app should run in a docker-compose environment. This allows easily share tests setup between developers and CI in environment that resembles a typical production. Note that the app under test should not neccesserily be part of this docker-compose and can keep on running locally - This is usually mor comfortable for developers
👀 Alternatives: Minikube, manual installation
✏ Code Examples
✅ Do: In a typical multi-process test runner, the infrastructure should be started in a global setup process - Most test runners have a dedicated hook for this. Otherwise, database will get initiated in every process which is very wasteful. In a development environment, it’s useful not to initialize the DB on every run - If the DB is already up, we can skip this step. See bullet about teardown which suggest stopping the DB only in CI env
👀 Alternatives: Invoke before the test command (e.g. package.json scripts) - Then tests can’t control the teardown
✏ Code Examples
✅ Do: In a typical multi-process test runner, the infrastructure should be started in a global setup process - Most test runners have a dedicated hook for this. Otherwise, database will get initiated in every process which is very wasteful.
👀 Alternatives: Invoke before the test command (e.g. package.json scripts) - Then tests can’t control the teardown
✏ Code Examples
✅ Do: As part of initializing the DB (via docker-compose) run the data migration. Since this is a time consuming operation - Run this only in CI or if an explicit environment variable was specified. To allow developers to migrate in a development environment, create a dedicated test command which includes the environment variable flag
👀 Alternatives: Migrate all the time
✏ Code Examples
✅ Do: Within each test file, initialize the app and the webserver inside the beforeAll hook (In mocha this is called ‘before’). Ensure to await for its readiness so the tests won’t try to approach when the server is not ready to accept connections
✏ Code Examples
✅ Do: Within each test file, close the app and the webserver inside the afterAll hook (In mocha this is called ‘after’)
✏ Code Examples
This repo contains examples for writing Node.js backend tests in THE RIGHT WAY including:
Just do:
Author: testjavascript
Source Code: https://github.com/testjavascript/integration-tests-a-z
#nodejs #node #javascript