- Test cases should be prepared by Automation QA but, Component and contract tests should be written by developers and reviewed by QAs.
- Component tests should simulate validation the same way a developer does during debugging, for example checking what data is sent in the event, what data is saved to the database, etc…
- E2E tests should be written by developers.
- Unit tests are optional
- Cover complex logic
- Run in the pipeline
- Tests optional, could be written to run manually to check that integration works
- Integration with external dependencies
- Repositories
- HTTP Clients
- Run locally, run manually during development, and remove after
In a microservices architecture, a component can be a single microservice itself.
- Use LightBDD testing framework to create human-readable scenarios
- Developers should mock external services HTTP clients using WireMock .NET
- Use local database hosted in docker, test database migrations
- Run tests using Microsoft Test server integration testing framework.
- Use in-memory mock for message bus.
- Automate manual test scenarios
- Run in the pipeline
- Developers should mock everything inside the controller
- Developers should cover authorization attributes and claims
- Developers should cover model validation and binding
- Test request validations and Authentication attributes
- should run in the pipeline
- Developers should cover internal microservices HTTP clients pact
- Developers should cover events contracts, pact messaging can be used
- should run in an independent pipeline, all microservices should check to verify compatibility
Test that the application started and run
- Test database health check
- Test External system HttpClient (call health checks)
- Run a simple smoke test for the main flow in the microservice