The Data Builder Pattern was introduced to me via Richard Bradshaw in this article. Richard got his inspiration from Alan Parkinson at a Selenium conference in 2013.

The data builder pattern is used to automatically create data in the system under test to increase the value of the automated test cases. The pattern is relatively simple and I will show 4 examples of how to use it in Leaptest.

The figure below shows the principles of the pattern:

data_builder_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.

Leaptest implementations

Leaptest is codeless, which means it doesn’t use the same methodology to implement the pattern, but instead uses a combination of building blocks to implement the Data Builder Pattern.

Database building block

The “Database” building block can be used for handling both Model, Builder and the Creator role. 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

database_bb_basic

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:

mongoshell_customer_query

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

read_excel_data_builder_pattern

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

mongo_example

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 setup the system under test. I.e. 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.

command_line_data_builder_pattern

HTTP Request

The final example of how Leaptest implements the Data Builder Pattern 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. I.e. users with different roles in the system under test.

Leaptest doesn’t have a build-in parser for complex return types (JSON, HTML, XML etc.) yet, so 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 as ready for the test.

Leaptest plans to create a parser for complex types shortly, which will ensure a better implementation of the Data Builder Pattern.

http_request_databuilder_pattern

Read Excel

One easy way of adding both the model and the data into Leaptest 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.

firstName

lastName

phone

Fiona

Hogan

319-9099

Robert

Wiggins

1-554-847-2734

Nolan

Quinn

1-398-818-0984

Jennifer

Reid

1-903-752-5103

Alea

Beard

212-1883

Heather

Bender

831-2152

Melissa

Serrano

976-9118

Mari

Head

591-9308

Victoria

Barker

759-7069

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

read_excel_data_builder_pattern

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, i.e. testing a simple signup form, this method can be useful and easy to implement and maintain.

Conclusion

The Data Builder Pattern is simple, yet powerful and increases the value of you automatic test cases. Leaptest has 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.

Learn more about codeless test automation with Leaptest

TRY LEAPTEST FREE
LEARN MORE