I saw some behat scenarios follow this pattern:

1. Configure the scenario
2. Login
3. Do some initial validations
4. Go to a course with editing mode on
5. Create a new activity (usually with: I add a "X" to section"Y" step)
6. Check something more in the activity form or in the activity itself

Points 4 and 5 are one of the most expensive steps in behat, forcing the scenario to add the @javascript tag only to navigate the platform. They are not testing anything, just navigating as a regular user.

It would be nice to have navigation steps directly to the add activity page without requiring go to the course page and have javascript. Implementing it is trivial and only requires adding the course name to the step to calculate the URL.

A quick search of I add a .* to section shows 56 results.

The proposal will be:

1. Create the new step that require not javascript and goes directly to the add form page: I add "MODNAME" to course "COURSENAME" section "SECTIONNUM".
2. Replace all uses of the previous step by the new one. This will include clean any previous I am on course page step because it won't be necessary anymore and also try to remove the javascript tag when possible.
3. Deprecate the step: I add "MODNAME" to section "SECTIONUM"
4. Execute all behats 3 times without the patch to get the execution time baseline.
5. Rerun behats 3 times with the patch to validate the performance improvement.

A bit of context on the course page and behat

The Moodle course page is intricate, implementing various cache levels in the front and backend. Additionally, some elements, such as the course index, are loaded asynchronously to prevent hindering the user experience. Only in edit mode certain frontend caches are not utilized to ensure the user receives the most up-to-date content.

When users navigate the same course pages repeatedly, caches and asynchronous loads are effective. However, this is not the case for behat tests, as most caches are wiped out with every scenario execution. The situation is even worse when the scenario has the @javascript tag because behat must wait until all javascript is fully loaded, and this includes all asynchronous parts that, in most cases, are not necessary to test a specific feature.

Technical shaping

This issue includes a step or locator to go straight to the add activity form.

There's a proof of concept on the last two commits of this branch:

https://github.com/ferranrecio/moodle/tree/MDL-78530-master-clr

The first tests where done during  MDL-78530 CLR and those are the execution time with and without the patch on the issue's feature file:

Without the patch:

run 1: 1m 51s
run 2: 1m 56s
run 3: 1m 51s

After some tests the executions times with the new step are drastically reduced:

Run 1: 0m 19s
Run 2: 0m 18s
Run 3: 0m 22s

The second test was on the completion/tests/behat/default_activity_completion.feature file. I only replaced the 3 navigation steps this time and kept the javascript tag. Even like this, the improvement is vast: from 4m 54s to 3m 53s.