Traffic Parrot has first-class support for the Service Virtualization Test Container Pattern (also called API Mock Test Container or API Simulation Test Container)
Let's assume if you work with a Jenkins Continuous Integration pipeline and test your microservices there to get to production fast. The more external dependencies the build pipeline has, the more risk you have those dependencies will cause the build to be unstable and fail because of external dependency issues, not related to the code quality. External dependencies should be kept to a minimum. For example, run your database in Docker per build (on Jenkins Slave), not in a shared environment. It is a pattern similar to the "sidecar" container pattern recommended by Jenkins just used in tests.
We recommend running your API mocks in the same process as your tests (and using Service Virtualization As Code - API Mocking As Code). If you decide to run your API mocks or virtual services in a separate process though, run them in a docker container. This way you are taking your automation to the next level, you have a fully automated and reproducible build pipeline.
Because of issues with dependencies, avoid using centralized instances running API mocks and virtual services outside your build pipeline. You can use them for exposing mocks to other teams and departments and for manual exploratory testing, but not in your automated CI builds.
Running in a container like Docker also means you are doing Infrastructure as code with all of its benefits to your business.
No comments:
Post a Comment