Testing exercises software and checks whether its output or behavior is correct. Start by running code and inspecting the result manually. As an application grows, repeated manual checks become slow; automated tests make those checks repeatable. Automation is especially useful when many microservices must keep working after frequent changes. For an early prototype or MVP, manual testing may still be enough. section 9.4 section 9.0
Choose the scope of a test according to what you need to check:
- Unit tests exercise a function or one aspect of it in isolation. Mock dependencies so unrelated code cannot affect the result. These tests are fast enough to run in large numbers. section 9.6
- Integration tests exercise a larger portion of code, such as a whole microservice. Start the service and use its normal interface, including HTTP requests or messages. section 9.12
- End-to-end tests exercise an application, or a manageable part of it, through the frontend. Docker Compose can start the application and Playwright can interact with it. section 9.12
A practical test suite usually has more unit tests than integration tests, and more integration tests than end-to-end tests. Broader tests cover more code per test but take longer to run. The right balance depends on the project and how long the team can wait for feedback. section 9.4 section 9.8.7
A first automated check
In Jest, a test named “can square two” calls square(2), then uses expect(result).toBe(4). The name states the behavior being checked, while the assertion records the expected result. For a microservice unit test, the same pattern can check a /videos handler: replace Express and MongoDB with Jest mocks, invoke the handler, and verify that it retrieves the required data. No real HTTP server or database connection is needed for that unit test. section 9.5.4 section 9.6.2
Run tests locally with npm test; a watch script can rerun them as code changes. Keep the test environment stable and, where practical, close to production. In a CI/CD pipeline, run the suite when code is pushed and use passing tests as a checkpoint before deployment. A failed suite then stops that change from reaching production. section 10.6.1 section 9.9 section 9.3
Table 9.2 Review of testing commands (view table figure)
Use the command table to find Jest and Playwright run and watch commands, plus the npm test convention. section 9.10
