How to Use the Data Builder Pattern in Test Automation

The Data Builder Pattern is used to automatically create data in the system under test. In this post, I will show how to apply the pattern using Leapwork to generate data and increase the value of automated test cases.

This Data Builder Pattern was introduced in a presentation by Alan Parkinson and further elaborated in this article by Richard Bradshaw.

The figure below shows the principles of the pattern:

The Model defines the input to a system under test. The role of the Builder is to create an instance of the Model and populate it with data, either from data local to the Builder or by using the Creator. The role of the Creator is integrate to the system under test to provide data for the Builder and to setup the system to be ready for the test.

Application in test automation

You can use the data-driven automation blocks of the Leapwork Automation Platform to implement the Data Builder Pattern. These are: the Database block, the Command-line block, the HTTP Request block, and the Read Excel block. I will go through each of them and how they relate to the Data Builder Pattern.

Database building block

The Database building block can be used for handling all roles of the Data Builder Pattern: Model, Builder, and Creator. By specifying an ODBC connection and a query, you will get access to each data row and and each field directly from the Database building block.

The Model and the Builder are combined into the building block. The Model is defined by the columns returned by the database query, and the Builder is implicitly expressed by the Method property (how to fetch data from the building block) and the schema returned from the query.

The Creator is the query itself - it can get data from a test repository, create new data in the system under test etc.

Here is an example of using a MongoDB. I have created a customer collection in the Leaptest database on the Mongo server. Using the Mongo console to get all data in the collection gives the following result:

Setting up a ODBC connection for MongoDB and using a "Database" block gives access to the fields found in the query:

Running the test case gave the following result (click to enlarge):

Command-line

The "Command-line" building block offers another way of "Implementing" the Data Builder Pattern. The "Command-line" building block can only return a text string from the command executed, so only one property will be available. If the response is line-based, the individual lines in the response can be iterated just like with similar building blocks.

The "Command-line" building block can execute everything that can be run from the cmd.exe. This includes PowerShell, which is a powerful tool that can access both databases and API's, and thereby set up the system under test. For example, the script could integrate with an ordering system and return either a list of customerIDs or orderIDs.

The Model is the single text property representing each line in the response from the command. The Builder is the access to the value provided by the command, and the Creator is the script running returning the values from the system under test.

HTTP Request

The third example of how to implement the Data Builder Pattern using Leapwork is the HTTP Request building block. This block can perform a HTTP Request (GET, POST, PUT, DELETE) and provide the response as properties to the building block.

This block could call an API and ask for a set of customers to be created, e.g. users with different roles in the system under test.

The Creator role in this case will be to return a simple result (customerID, orderID, sku etc.) or just to signal that the system under test is ready for the test.

Read Excel

One easy way of adding both the Model and the data into automation flows with Leapwork is the use of Read Excel building block. By reading the columns of the data range in the specified Excel sheet, both the Model, the Builder and the data are included in this single building block.

The data range shown above will give a Read Excel building block looking like this:

This approach is not implementing the full Data Builder Pattern because there is no integration/assurance that the data is available or matches the system under test. In scenarios where the test is less bound to the exact data and the system under test scales well, e.g. testing a simple signup form, this method can be useful and easy to implement and maintain.

The Data Builder Pattern is simple, yet powerful and increases the value of your automatic test cases. Leapwork offers various ways of implementing parts of or the whole pattern: direct database access, HTTP requests, command line tools and the more static Excel-based approach.