Explore Data-Driven Testing

Learning Objectives

After completing this unit, you’ll be able to:

• Explain the purpose of data-driven testing.
  
• Explain the features and best practices of data-driven testing.
  

What Is Data-Driven Testing?

Data is important to testing. Whether a contact or contract, most testing flows include some form of data. As a testing methodology, data-driven testing (DDT) uses data to drive test design and execution.

Think about an example. You need to test the flow of creating a Lead. There are four required data inputs for this flow: first name, last name, company, and email address. One option is to write the first name, last name, company, and email address for the Lead directly into the test case. This is known as hard-coding values. They only change when you manually update them in the test case.

While this certainly could work, it would also have some limitations because it depends on that exact input each time the test is run. Consider the values for each input below.

If the first name is entered as Siera or Ciarra, the test fails. If the company is entered as Luna Tunes instead of Lunar, it fails. And if you need to change any of these values, you have to go into the test case to do so.

There’s another option for the values in this table: data-driven testing. With this methodology, the data is stored externally and read into the test case when it executes. CSV, Excel, or other databases serve as external data sources. Rather than manually hard-coding the first name, last name, company, and email address, that data is stored separately and brought into the test case when it executes.

Simply put, the data drives the test.

Create Data-Driven Tests

Parameterization

A quick start to data-driven testing is parameterization. Recall that a hard-coded value is a set value, so each time you run a test step with a hard-coded value, the test expects that exact value to pass the step. Using hard-coded values can lead to unnecessary failures or difficult and time-consuming maintenance on your test cases. One solution for this is to use parameters, or variables, that can change and populate the test case with different data.

Ciara, Jones, Lunar Movies, and cjones@lunarmovies.com are all hard-coded values in the example above. If you update the data for the email but not the test step that verifies it, the test step fails. If you use a parameter, though, it can change and populate the test case with different data.

Data Sources

External data sources make your test cases easier to maintain. With your data separated from your test logic (that is, the steps), you only need to make changes to the data source to keep your test up to date. When you execute the test, the file of data loads into the test, populating all the data in the test case where input is needed.

With an external data source, you can also broaden your test coverage. The wider your test coverage, the more you learn about your application. Positive and negative flows are a good way to think about this.

We often see testing explained through positive flows, or happy paths. A positive flow checks that what is expected to happen does in fact occur. For example, when you set a date in the present or future, the step should pass. However, negative flows also provide valuable information. Testing a negative flow checks that a test fails when something that’s not supposed to happen occurs. In this case, when you set a date that’s in the past, the step should fail.

Data-driven testing makes it easier to include negative flows because you can reuse the same set of steps with different inputs. One set of test steps with multiple sources of data yields greater test coverage.

Looping

Looping takes the external data source and increases its efficiency. Look at that Lead data again, but now with two rows of data.

Instead of entering each row individually into a test case, you can read in the data from the external source and loop through the test steps with the data in each row. Now the same actions are performed for every row.

Looping becomes increasingly valuable as your data sets get larger. As long as you keep your data source updated, your test data is current. By using a single test case for many input parameters, you can save time and minimize errors.

Best Practices

There are a few practices to keep in mind with data-driven testing. Above all, know that your tests are only as good as your data. Your team should set and follow conventions for making external data sources accurate and accessible.

Start by keeping your data organized. Use naming conventions for your test data and ensure that they’re used consistently across your org. This makes your data clear to yourself and others who access it. Speaking of access, decide as a team where to store your data so that you know where to find it and your team can access it without you. Finally, keep your data current with any changes in your application.

Benefits

Now that you learned a little about creating data-driven tests, review some of the benefits.

• It makes your tests dynamic. Writing hard-coded values into your test cases risks making them brittle and difficult to maintain. Data-driven testing uses variables to make your tests more dynamic.
  
• It increases efficiency. Instead of writing the same series of steps over and over for different pieces of data, derive your data from a data source to input your data through one set of steps. Loop through data sets when you have multiple data permutations.
  
• It improves test coverage. Test a wider range of scenarios using different input parameters. This ensures that your application doesn’t work with just one set of data.
  

As you learned, DDT has a lot to offer, but it’s just one methodology. In the next unit, you look at another popular approach called behavior-driven testing.