Page History
...
If you are thinking on using Tests as steps in other more high-level Test case you should consider modular tests and not using implicit/embedded clones.
...
- Perform the same Test but against different data
- Use test parameterization and datasets, this will allow the correct replacement of the parameters by data defined by the dataset. As you can see in the documentation you can define the dataset in different entities or scopes of your tests.
- Cover/test different requirements, of different projects; in this case projects may be somehow similar and may represent slight variations/conditions of the "main requirement"
- You may use the same Test for this (probably the Test would reside in some common project); however, if you do so, then the Test result will affect related requirements in the same way (unless you change the Separation of Concerns setting). Instead, and because you're probably really talking about different requirements, the best is to have specifically designed Tests for each individual requirement
- E2E Test composed of steps, where these steps are essentially existing Test cases
- In this case, if you have defined some Tests that can be used as modules in other Test steps, you should use modular tests to include other Tests as steps of a more high-level Test case. Make sure this will focus the Test in the feature you want to validate and not in the feature of the Tests you are including.
- You can also design the E2E Test in such a way that its steps are more simple and validate only what is the purpose of the E2E Test itself (e.g. instead of having an E2E Test with all the steps of a login related Test case, the E2E Test can have just one step where the user is expected to login using given username/password)
- Tests having some common initial steps
- Abstract those common initial steps in reusable Pre-Conditions linked with all those Tests
...