Creating Dynamic Testing and Mocking Assets in Your CI/CD Pipeline
Testing very early in the development process can improve overall quality and efficiency. BlazeMeter has the ability to be integrated with CI/CD tools to run performance and functional tests as part of the build process. Something you may not know about BlazeMeter is that, as well as automating your tests, BlazeMeter can also dynamically create Test Data and Mock services. In this blog post we will talk about how Test Data and Mock Services can be incorporated into the build process to improve your test coverage and improve overall build quality even more.
Generating Test Data Dynamically
BlazeMeter has had the ability to store static test data in CSV files when running performance and functional tests for a long time. These CSV files can also be shared across multiple tests. But, did you know as well as using static test data in CSV files you can also dynamically generate test data? This data can be based on predefined rules, which removes the challenge of maintaining and refreshing CSV files.
Synthetic test data generation can also be used in conjunction with existing CSV files. This allows flexibility when defining your test data requirements. Using Synthetic data removes any dependency on production data and the security risks that can be incurred when using production data for testing.
Rules can be used to generate multiple types of synthetic test data. This includes names, addresses, credit cards, birth dates, etc. When a test is initiated, the test data is automatically generated and can be viewed as part of the test results. By utilising the power of BlazeMeter’s built-in seedlists, our built-in lists of sample test data, you can be sure that the data will be consistent and appear in the correct format.
For example, you might have a test that validates a user registration form. This form requires the user’s address to be entered in multiple fields (i.e street name, city, state, zip code, etc.). By using the multi column seedlist, you can ensure that the city, state and zip code are all valid. You can also utilise your own CSV and JSON files instead of seedlists,
This is an example of synthetically generated data using a combination of seedlists and test data functions:
Mocking Your Services
BlazeMeter can also provision mock services. An initial question that arises might be: Why would I need a Mock Service as part of my CI/CD pipeline? There are many examples where mock services are an invaluable tool. For example, when you are relying on a third party API that may not be readily available or may have a cost incurred to use when testing.
Wouldn't it be great if you had an API available on demand and could also control the response from the API? This would enable testing multiple use cases. Perhaps an API required as part of your solution is still under development. So instead of waiting for the API to be made available, you can use a mock service.
BlazeMeter can be used to record an existing API and simulate that API endpoint inside or outside your firewall. These Mock services can be associated with tests to ensure that the end point is always available when a test runs and that the relevant API responses are available to ensure seamless testing.
Here is a simple mock service configured with three transactions. Mock services can be built using the UI and a proxy recorder or they can also be created using the Blazemeter API. We will discuss this in more detail later on.
Mocking Requests with Transactions
Remember, a BlazeMeter mock service is not just an endpoint. It can also be dynamically configured to respond to specific requests. These requests are called transactions and are stored in the Blazemeter Asset Catalog.
The Asset Catalog can be shared with multiple development teams, allowing teams to start testing an API’s responses before it has been fully developed. Any changes made to the API will automatically be updated in the mock services. Transactions can also be created for testing negative test cases and to validate how invalid responses are handled.
You can load transactions individually into a mock service or bundle them into templates. This is a great way of grouping transactions and simplifying the updating of a mock service.
For example, your application may rely on a third party credit card validation API, and you’d like to test how your application works with declined requests. A template that contains all transactions relating to a declined credit card could be created. By selecting this template from the test configuration screen, all relevant transactions will be loaded into the mock service when the test is started. The test configuration screenshot shows how a mock service and template can be easily associated with a test. When the test is initiated the mock service will be dynamically updated and started if required.
So far we have talked about how we can include test assets like mock services and test data as a dependency of a BlazeMeter test. This means that if you initiate a test directly from a tool like Jenkins, the provisioning of the test data and mock service will be automatic. In the next section we are going to discuss how you can use the Blazemeter API to fully leverage the BlazeMeter platform from a CI/CD tool like Jenkins.
Mocking with the BlazeMeter API
The BlazeMeter API gives you the ability to do more than just run tests. You can also instrument all of the BlazeMeter functions. An example of this could be building and initiating a mock service.
In this example Groovy script, which you can also view on GitHub here, the Blazemeter API is used to create a mock and start the provisioned mock service. The mock service endpoint can then be used to configure the System Under Test. The API payload contains the details for the transactions to be deployed and this can be a template or specific transactions as in this example.
Utilising the API, a mock service can also be deprovisioned at the end of a testing cycle, if it is no longer required.
If test data requirements need to be changed for specific tests, the API can also be used to update the test data model. This allows the data model to be modified to incorporate build specific details such as build numbers As you can see from the Groovy script example from above, the data model payload contains all of the details for the test data model.
The API payload in this example may look complex but it can be easily broken down into two blocks of data. The properties is a list of the data model parameters and type, and for each parameter (property) there is a corresponding requirement that contains the data model rule / function. In the example I created a parameter called jenkins_build with the corresponding requirement of the jenkins_build number.
Once a test has run, the test data used for the test is available on the test results screen. This is a sample of the test data showing the Test Data that was generated showing how the name and email address are consistent as well as the city and state.
These are just a few examples that show how you can leverage the power of the BlazeMeter platform to automate your tests. For more details about BlazeMeter click here, and you can also read more about using Mock Services and BlazeMeter test data. To get started, sign up now.