In test automation, there are often cases where you might have multiple data sets for which you need to run the same tests on. This approach has been described with several names, including data-driven testing, parameterized testing, or table-driven testing. In mabl, we call it data-driven testing, or DDT. This is the process of loading data that is external to your functional tests to strengthen and extend your automated test cases. It is now possible to create tests that you then parameterize to run across several different inputs.
A data-driven test performs the following operations several times:
- Retrieves a portion of testing data from data source.
- Enters and utilizes data in an application form.
- Verifies the actual results with the expected results.
- Repeats this test with the next set of input data.
There are a number of benefits of making your tests data-driven. Some include:
- Reusability: any test script can be written and re-executed hundreds or thousands of times, with different inputs each time
- Versatility: a data-driven test is usually associated with a single test or procedure, but can be used in several test cases
- Efficiency: data-driven tests can generate test scripts with less code
- Separation of logic: data-driven tests allow for the clean distinction of test case logic from the actual test data
- Stronger test coverage: you can continually change the input test data and cover a broad scenario of inputs
Data-driven variables are the building blocks of data-driven testing. By definition, these variables get their values before a test or flow starts running, and they come from a few different sources:
A test that is associated with a DataTable generates one run for each scenario, or row, of the DataTable. Each DataTable scenario contains a set of variables that is passed to the test. The value of those variables is determined by the scenario.
Shared variables are values exported from a test that is configured to share variables to another test in the same plan.
If a value is not supplied from any of the previously mentioned sources, mabl will try to use a default value stored with the test.
Data-driven variables can be stored at the test level in two different ways:
- Variables > Create variables > Set variable using Data source
- Variables > Manage the variables in this test > Add variable
See test data-driven variables for more information on this source.
Flow data-driven variables are variables in a flow that have their value set from a different source, such as a prior test step, an environment variable, or a DataTable scenario. To describe it in a different way, if a flow uses a variable that was created outside of the flow, this variable is known as a flow data-driven variable.
Order of precedence for variable values
If multiple values are passed to a test for the same variable, the following order takes precedence: DataTable scenario > Shared variables > Values stored with the environment > Test data-driven variables (default values) > Flow data-driven variables (default values).
The value coming from the DataTable scenario will overwrite other values.
Updated 5 months ago