DDSteps Explained

The Problems

When performing integration testing, functional testing, or acceptance testing, it’s common to run into some or all of the following problems.

Managing Test Input: Imagine that you have a long list of functional test cases that your application should suffer through. Each test should be performed using several different types of data. For example, the login test should be run using a European user, an Asian user and an American user. Different roles? OK, test logging in as a European with Admin role, a European with User role, etc. The point here is that the test is the same, but the data is different. We would like ‘something’ that reads test input data from ‘somewhere’ and runs our test once for each row of test data.

Managing Test Fixtures: A functional test usually require some basic test data to be in place before the test starts. In order to be able to log in as certain users, for example, we need those users in the database. Their roles are needed as well. We would like ‘something’ that sets up the database with “test fixtures” before each run. Or the LDAP, or whatever we use for storing data.

Repeating Test Steps: When specifying a functional test of an application with an interactive user interface, like a web application, you tend to do the same things over and over. Go to the start page, click the login link, fill in the credentials, click Submit, verify login successful. We would like to save those steps as building blocks and put them together in different combinations for different tests. And have the ‘something’ read the test data from ‘somewhere’ into the blocks that need test data.

The Solution

DDSteps can do it all for you. DDSteps is an extension to JUnit, the testing framework you most likely already use. DDSteps has three important capabilities:

  • Data-Driven Test Input
  • Externally Stored Test Fixtures
  • Reusable Test Steps

Data-Driven Test Input The “DD” part of the name refers to “data-driven”. This means that the test code reads test input and expected output from some external source, like an Excel sheet or an XML-file. The test is then executed once for each row of test data. The data for each row is automatically pushed to the test code, thus making the test code data-driven.

Externally Stored Test Fixtures Test fixtures are data sets relevant for the tests. For example, when testing the login functionality, there must be users to login as. Sometimes there are more complex dependencies, like when a user needs a company in order to be valid. In that case, the fixture must include valid companies as well. And so on. DDSteps can load fixtures from a variety of external sources, like Excel sheets or XML-files. The data is then inserted into a data source. DDSteps supports relational databases, LDAP and file system.

Reusable Test Steps DDSteps can load test data into test steps. A test step is a building block that performs some limited functionality. The steps can be of the following types:

  • A Navigator navigates to a certain “place” in the application, preparing for the test.
  • An Executor executes some functionality, but does not validate the result. This increases its reusability.
  • A Validator verifies that one or more Executors produced the expected result.

These test steps can be combined together to a fully executable test, which then becomes readable like a test specification: 

testLoginSuccess() {
	navigateToLogin.run();
	executeLogin.run();
	validateLoginSuccess.run();
}