Embed Virtual Services in a Taurus Script

The Taurus automation testing framework now includes definitions to add virtual services within a Taurus test file. As long as the virtual service already exists in BlazeMeter, you can include it in a Taurus test definition file.

Taurus includes a dependencies node that allows you to define dependencies; mock service is the first dependency you can define.

To include a virtual service in a Taurus test, define the following nodes in your Taurus file:

dependencies: The root node and parent object for the inclusion of virtual 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 BlazeMeter Service Virtualization. You can define more than one Service as needed, but at least one is required.

mock service: Child node of service. Defines the virtual service to use as the virtual endpoint for hosting the Transactions to test against. You can define more than one virtual service, but either one virtual service or one tag is required.

mock service template: (Optional) Child node of service. Defines the Template from which to load Transactions into the virtual 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 virtual service. If you define Transactions separately, they override the Transactions provided directly in the virtual 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 appears.
• 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 virtual service. At this time, you can only filter by tags. When you enter filter criteria, the filtered Transactions override the Transactions provided in the virtual 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 virtual 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 virtual 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 virtual 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 virtual service from the Template or the inline Transaction definitions.