Forum Discussion
JoostDGThanks for the reply. Sadly none of the suggestions are quite what I'm looking for.
For the polling example we do use the following a lot, as it's mostly the preceding test step:
testStep = context.testCase.getTestStepAt(context.getCurrentStepIndex()-1).getLabel()
As you already said "Of course, if you start changing the order of the target test steps this will no longer work neither."
Unfortunately for us, that is also something we do quite a lot, adding new test steps..
CONTAINS.. might be more groovy, but robust? 😉
I feel this would just add insult to injury: instead of at least knowing what's happening it'd become pretty much random if a test case ends up broken or not after a test step name change. If you managed to remember what you're allowed to change it would work of course. But that'd basically require a naming convention based around this.
Could work in a new project, but we already have around 10k test steps in our project.
getTestStepById() might be robust, but indeed nowhere near intuitive enough. When designing/maintaining it would be too much extra effort, as you can't easily see the GUIDs in the UI.
And even if you could, as GUIDs are not easily compared at a glance, it would be hard to quickly see what test step it is actually referring to.
Understand the problem.
Changing the step is common because of various reasons.
Why not fix the test step name if at all possible? just to quote, "step 1" is not a good naming convention. Please give the meaningful name to the step so that you wouldn't have to rename so frequently.
To your point, renaming step name is get replaced in all place of project including groovy script references (example you pointed context.expand), but not in other assignment, because of the fact that it is a string literal (no reference).
Another chance is that if you know (i am sure you would) the method type, interface, name etc of a step, then it is possible to get the step dynamically. Of course, if the same type of request is used multiple times in same test case, will again have problem.
- rse2 years agoNew Contributor
Thanks for the reply.
Switching to a better naming convention is actually our main cause of test step renames.. 😉
Using the same type of request multiple times in a test case is not uncommon in this project either. Also, if you would use that, dynamically by method or whatever, or something like CONTAINS as suggested in the other reply: it gets harder for a human reader to understand what is actually being pointed at, and if it still is correctly being pointed at.
Basically we want to point to a test step with a reference instead of a string literal, so that it automatically adjusts. But for human readability it should still include the test step name.
Related Content
- 6 years ago
- 10 months ago
- 13 years ago
Recent Discussions
- 15 days ago
- 22 days ago