The Taurus automation testing framework now includes definitions to add Mock Services within a Taurus test file. As long as the Mock Service already exists in BlazeMeter, you can include it in a Taurus test definition file.
Taurus now includes a dependencies node that allows you to define dependencies. Mock Service is the first dependency you can define.
At this time, all entities you define as dependencies in Taurus must already exist in BlazeMeter.
To include a Mock Service in a Taurus test, define the following nodes in your Taurus file:
dependencies: The root node and parent object for the inclusion of mock services in a test definition file.
service: Child node of dependencies. Defines the Service or Services that contain assets that are dependencies for the test. Enter a Service name that exists in the Mock Services area of BlazeMeter. You can define more than one Service as needed, but at least one is required.
mock service: Child node of service. Defines the Mock Service to use as the virtual endpoint for hosting the Transactions to test against. You can define more than one Mock Service, but either one Mock Service or one mock-services-by-tags is required.
mock service template: (Optional) Child node of service. Defines the Template from which to load Transactions into the Mock Service. The Template must exist in the defined Service. If you do not define a Template, the test takes the Transactions from specific Transaction definitions in the Taurus file.
transactions: (Optional) Child node of service. Defines the specific Transactions to include in the Mock Service. If you define Transactions separately, they override the Transactions provided directly in the Mock Service. The Transactions must be in the repository and exist within the defined service.
- The transaction names within the same service must be unique. If you name a transaction that is part of the same service with the same name that already exists, an error message shows.
- Individual transactions not contained in a template do not have priorities associated with them.
There is no priority at the transaction level as the same transaction might have a different priority in various services.
transaction-filter: (Optional) Child node of service. Defines filter criteria for Transactions in the specified Mock Service. At this time, you can only filter by tags. When you enter filter criteria, the filtered Transactions override the Transactions provided in the Mock Service.
tags: (Optional) Child node of transaction-filter. Defines the tags by which to filter the Transactions in the test. For example, entering a value of Positive includes only Transactions with a tag of Positive in the Mock Service. You can include more than one tag by using separate lines for each tag. Multiple tags are connected with OR criteria.
Example Taurus file with dependencies defined
execution:
- iterations: 50
concurrency: 100
ramp-up: 1m
hold-for: 5m
scenario: quick-test
scenarios:
quick-test:
requests:
- http://my-application.com
dependencies:
services:
- service: Identity
mock-service: IdentityMock
mock-service-template: Identity (OK responses)
- service: PaymentGateway
mock-service: PaymentGatewayMock
transactions:
- ProcessPayment
- AddPaymentMethod
- RemovePaymentMethod
Here is an explanation of the dependencies in this Taurus script:
Within a Service named Identity, the test requires a Mock Service named IdentityMock. The transactions included in the IdentityMock service are defined in the Template named Identify (OK responses).
Within a Service named PaymentGateway, the test requires a Mock Service named PaymentGatewayMock. The Transactions included in the PaymentGatewayMock are listed individually using the transactions node.
When you run this test, the Transactions are loaded into the Mock Service from the Template or the inline Transaction definitions.
