Indicate when XHR's match aliases multiple times, and correlate those to waits

[brian-mann]

Current behavior:

There's not an easy to know or correlate multiple matched XHR aliases to knowing how to wait for them.

Here's an example screenshot:

The problem is that the user is trying to wait on the 2nd XHR. But since they've only added a single cy.wait("@getTable") Cypress only waited on the first XHR to resolve.

Desired behavior:

When an XHR matches an alias multiple times we should add a number indicator next to it...

(XHR) /getTable @getTable
(XHR) /getTable @getTable.2
(XHR) /getTable @getTable.3

So then when adding code like:

cy
.wait("@getTable")
.wait("@getTable")
.wait("@getTable")

The command log would actually look like:

WAIT @getTable
WAIT @getTable.2
WAIT @getTable.3

[bsmithEG]

Any news on this one? There's a circumstance where I need to actually check if the same XHR gets requested N times, so I'm encountering this issue.

[itaykotler-fundbox]

Hi @brian-mann, any progress with this issue?

[jennifer-shehane]

@bsmithEG There actually is an undocumented way to check the number of times an XHR was responsed to using .all on the alias.

cy.wait('@getRuns')
cy.tick(10000)
// should have done 2 request responses, and definitely not 3
cy.get('@getRuns.all').should('have.length', 2)

[lilaconlee]

Played around with UI options a bit, would love any opinions. @jennifer-shehane @chrisbreiding

Ordinal:

Cardinal:

Tooltip:

Labels for stub:

[chrisbreiding]

/cc @brian-mann ^

I like the ordinal version. For the stub itself, I like only having 3 with a tooltip saying something like "This event occurred 3 times".

[jennifer-shehane]

I think that the numbers by themselves is a bit tricky because it's so close to the stylings for when we print the number of elements found for a command.

But I also think that the ordinal numbers are very English-centric, as ordinals are printed differently in each language. They also take up more room, which is a negative.

I would also make sure that you take into account there being 3 digit numbers - someone will have 100+ requests

Maybe an alternative would be to write the number beside the printed alias...so:

WAIT      @getFoo | 1

[lilaconlee]

Some iteration, think I'm liking the first one so it keeps the visual relationship with the original stub.

[brian-mann]

@jennifer-shehane if you can experiment with some of the designs...

I'm kind of thinking of something like this...

I think we should connect the "number" with the alias, and tweak the tooltip messaging. Offering a "(?)" link next to alias also might be a good idea to help communicate how this actually works.

[brian-mann]

Just like how counting the DOM elements works, I don't think we need to include anything if the event happens once, but do include the numbering for every subsequent event.

[lilaconlee]

I'll do something more like this for now for when there are more than one

[lilaconlee]

PR'd in #2960, screenshots of that below.

One topic I'm not sure on:

• Showing the counts for all aliases/references, not just ones that were fired multiple times. Changing the design to always show the count was brought up at the most recent test runner meeting. This was my original implementation, but got some feedback to change it. Am definitely down to change it back as it cuts down on branching logic. Main downside would be the case where you only have one fired alias, the count might seem out of place.

Some topics we discussed but I didn't implement:

• Adding more emphasis to collapsed stub so folks know it opens. (now that we show the numbers on the aliases, not that important to see the duplicates)
• Adding alias counts to collapsed duplicates (didn't for same reason as above)
• Updating the similar UI for DOM elements (not the same usage, doesn't make sense to have the same UI)
• Showing the range of the counts found, like "1-4" or "1...4" (all of the options I came up with seemed more confusing, seems explained by the tooltip)

A couple of different scenarios with aliases:

With duplicates open:

[chrisbreiding]

The code for this is complete, but not yet released. It will be released in 3.3.0. At that time, we'll post a new message referencing the changelog.

[cypress-bot]

Released in 3.3.0.

[danieljosephbrennan]

This is just what I need, but I can't find anything in the docs.
How would I wait for the nth instance of a particular call?

[strass]

Graphql only has a single endpoint so we have cases where we load the same URI multiple times on the page. I don't see any suggestions on how to wait for a variable number of requests in the docs. I would love a way to wait for all routes of a certain alias to finish, such as cy.wait('@graphql.all').

#3308 has some suggestions but doesn't work in this case