Serenity-core: Error with expandable behavior

[ricardorlg]

1718 adds the feature of having expandable steps in nested steps, but it looks like it assign the same id for all the steps, so when I try to expand one substep it applies the action to the first one, which causes That I'm not able to see other nested steps or even worst the exceptions that happen on assertions.

C.C @wakaleo

[jasonex7]

I have the same issue. I'm working with Serenity 2.0.65 with Serenity JBehave 1.46.0

[wakaleo]

Please take a look at the default.ftl template and see if you can propose a PR that fixes the issue.

[ricardorlg]

@wakaleo I found that one of the reasons that cause that the expandables doesn't work in the report is when for example I have a Task that inside call other tasks, and I use the Step annotation to define the description If I change Step to StepGroup everything works in the Reports.

So for me, thins is a workaround, I will close the bug if it is ok for u John.

[wakaleo]

This is weird because @StepGroup hasn't been needed for a very long time (in the code it is synonymous with @Step), so I'm a bit confused as to what is causing this. I suspect it is a bug. Can you provide a simple sample project?

[ricardorlg]

I think it's related to the fact that the PR that adds the expandable, uses the fact that a step is a TestGroup, So when he receives a task this one is marked just as a step, and if inside there are other tasks Serenity doesn't know what to do.

I will make an example project just to be sure about this.

[wakaleo]

The isAGroup() method in the template just checks whether a step has children (it is not related to @StepGroup, which is effectively deprecated).

[ricardorlg]

Yes u are right, I test the StepGrop in another project and the bug appears, I will try to check in the project that it's working what could be the reason.

[ricardorlg]

More info, AFter a lot of tests, I found that in my case this Bug happens if u have steps that repeat in same scenario.

[shaundsmith]

When I originally implemented the change I used a variable to keep track of the substep count (for use as the ID). From what I can tell, the ftl variable isn't scoped specifically to the macro, so when we have multiple levels of nesting across multiple steps the substep count goes out-of-whack.

I've managed to replicate the issue locally and I believe I've fixed the issue. I've committed the changes to my fork in the branch "collapsible_nested_steps" (https://github.com/ShaunyPrawn/serenity-core/tree/collapsible_nested_steps)

@ricardorlg if you get chance, could you give your tests a run against my fork and let me know if this fixes your issue please? If it fixes your issue I'll get a PR raised.

Cheers

[ricardorlg]

@ShaunyPrawn sorry for the late reply I have been busy, can u just give me the steps to build ur fork so I can try to test it.

[nbarrett]

Hello @ShaunyPrawn and @ricardorlg - good news - I've built collapsible_nested_steps branch locally and I can't see anything wrong with the expansion now. I've just raised https://github.com/serenity-bdd/serenity-core/pull/1780 which awaits merge 👍

[ricardorlg]

@ShaunyPrawn It works to me too, I think the best is to merge it so we can have more feedback

[shaundsmith]

Cheers for verifying this and thanks for raising the pull request :smile:
Apologies if the issue has caused any disruptions.

[JeffGaly]

@ShaunyPrawn is this issue fixed?