How To Import Data Tables for Data-Driven Testing
Data-Driven Testing with TestBench sounds really cool. But how the heck do I get data tables into TestBench to try it all out? Our TestBench product owner has also been confronted with this problem several times in the past. Here comes his easy to implement solution.
As the Product Owner of TestBench CS, I sometimes face challenges not every user has. Recently, with the newly published feature of Data-Driven Testing, I needed to try that very often. Since I didn’t want to keep re-entering the data tables, a data table import tool was required. Well, I think THAT is something every user could need.
So I would like to share with you how I solved my problem. You can download and use my tool, or maybe you create your solution with TestBench CS?
The API of TestBench CS gives you access to any feature of TestBench CS. As we are discussing tables, I figured Excel as a typical table editor was the perfect platform to use this API.
Every decent IDE can address the REST API offered by TestBench CS, but Excel VBA has been designed long before REST APIs became en vogue. Thus, to make life easier, I’m using a library (“Webhelpers” by Tim Hall – thanks, Tim! https://github.com/VBA-tools/VBA-Web) which makes firing REST calls a breeze.
Additionally, to make life even more comfortable, I’m using a wrapper function, “ApiCall,” which handles a few clerical things for me (written by my colleague André, thank you, André!).
The first thing we need to do in our Excel VBA Macro is logging on to TestBench CS.
The call for that is, according to TestBench CS Swagger docu
POST /api/tenants/login/session
Logs on a user.
Example Value
{
"force": false,
"tenantName": "string",
"login": "string",
"password": "string"
}
In Excel VBA, it looks like this:
' Add parameters to the request JSON
Set dict = New scripting.Dictionary
' Force login, logout other sessions of this user
dict.Add "force", True
' Login data is read from "import_settings.ini", see module mIniFile
dict.Add "tenantName", ReadIniFileString("User", "Tenant")
dict.Add "login", ReadIniFileString("User", "Login")
dict.Add "password", ReadIniFileString("User", "Password")
Dim response As WebResponse
' Execute the request and work with the response
Set response = ApiCall(HttpPost, "tenants/login/session", dict)
The actual call is triggered in the last line. Before we kick it off, we need to provide the parameters: We use a Dictionary for that. In the Dictionary, we add values for the parameters “force”, “tenant Name” (aka Workspace), “login,” and “password”. While most of them are self-explanatory, I have to explain the first one briefly: if a user is already logged in, if set TRUE, “force” will result in logging the user out; if set FALSE, the login process will be terminated.
The prepared Dictionary is passed as the body, or payload, for our REST call.
If successful, the response will give us some information we store for further reference. The most important bit is the session token: It is required for every other call.
One more word on the “clerical” things the function “APICall” does for us: another typical call we need for our enterprise is the one that returns the content of a table. It looks like this:
GET
/api /tenants /{tenantId} /products /{productId} /ddt /testCases /{testCaseId} /tables /{tableId} /v1
Fetches a table
Parameters
Name Description
tenantId * The identifier of the tenant.
productId * The identifier of the product.
testCaseId * The identifier of the test case.
tableId * The identifier of the table.
This call does not expect a body – the Dictionary we provided with the login – instead, it has parameters embedded in the URL, e.g., “{tenantId}”. If we store those values in the expected way (for simplicity, we’ll just use global variables), the “APICall” function will replace placeholders in the URL in a proper way, and take care to use the session token properly, too.
If you follow this pattern, you can write your tools that access TestBench CS based on the API. So what can my table import tool do for you?
- Import a table to TB-CS and attach it to a test case that has no table attached
- Update an existing table using the proper IDs of columns and rows, if the IDs are stored in the Excel file
- Update an existing table based on the names of columns if no IDs are given, and add rows
- Delete a (just created) data table from Testbench CS
This is merely an example of what is possible if you use the API of TestBench CS. Mind, I don’t think of myself as a developer; I’m just a tester and a product owner. If I can do these things, indeed you can!
Do you want to try what I described in my blog post for yourself right now? Here you can find the prepared Excel file and a .ini file for importing the table settings.
I can’t wait to hear what great things you achieve with the API!
Feel free to show us your ideas. We would love to know what you have done with the TestBench API!
