Automated tests can be run multiple times with different values by parameterising tests. Parameterising your tests can improve test coverage because a value in the test can be parameterised which means that the test can iterate through a number of values. This enables one automated test to cover a number of test cases. You could, for example, write one test that checks the behaviour of the application on entering a text string, and then parameterise the test to run with a number of different text strings.
Parameterised tests also have less code to maintain because one parameterised test covers multiple test cases.
When a test has been parameterised it is also easier to see what tests have been created because you can review the array holding the parameters rather than read multiple test cases.
You can, for example, parameterise tests using Playwright.
When you parameterise a Playwright test you will need to parameterise the test’s name because the test’s name is used in the name of the screenshot. If the value of your parameter can be used in the test name and in the test you can use an array of strings to hold your parameters. Playwrights documentation shows you how to parameterise a test with an array of strings: https://playwright.dev/docs/test-parameterize.
If there is more than one value that you want to parameterise then you will need to hold the values in a data structure such as a typescript interface. The test can then use a for loop to iterate through an array of objects which means that you can change a number of values each time the test is called. A simple example in which three values are changed each time the test is run is shown below:
Other test automation tools offer similar functionality for parameterising tests to Playwright, for example:
- Jest has it.each, which enables tests to be run asynchronously with different data
- Jasmine tests can be parameterised with forEach
- Cypress tests can be parameterised with forEach
- The low code automation tool Ghost Inspector supports data-driven testing, which is very similar to parameterising tests.
- Selenium has a data-driven framework
- Cucumber has a data-driven framework
TestAndAnalysis 
Parameterizing tests (particularly for high(er) level parameterization) also allow for refactoring (or changing) of the test tooling or low level test logic for UI element locators and the actions performed on them.
As an example, abstracting a sequence of actions to select a color into one (page object) method, and parameterize it to allow for selecting any color in the test. I have seen cases where the automation staff did not abstract it and/or didn’t parameterize, hard coding it to a single color which could fail if the color no longer existed and take more work to update test than a simply switch of color name if parameterized well.
LikeLike