The rule of thumb for dealing with data is, like with keyword design, not to do anything twice. This means that you should set data that will not change 3.9.2 and parameterize data that will change 3.9.3.
Keywords that enter text, select from trees and check boolean values are all likely to need referenced parameters so that you can specify each time you reuse the Test Case what text to enter, what to select, and whether you expect a true or false result.
Parameters that deal with operators, search/path types, timeouts and delays can generally be fixed for your keywords and do not need to be parameterized. This reduces the amount you have to enter each time you reuse a Test Case and also means that data that will remain the same can be managed in a central place.
![]() |
Don't worry if you are not sure at the beginning what will or won't change. You can add parameter references later in the Properties View and can remove unnecessary references in the edit parameters dialog 3.9.4. |
If your Test Case needs to refer to the same data more than once, it may be worth thinking about parameterizing the data to the parent Test Case , so that you only have to enter the concrete data once. So, if your test creates a new project and then checks to see if the project name appears correctly, you should probably have the project name as a parameter of the whole Test Case to avoid having to enter the name in two places.
Alternatively, storing the data in a variable or as a central test data set may be another way to avoid having to enter the same data more than once.