Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
brian-mann opened this issue Mar 27, 2017 · 15 comments
Closed
Assignees
Milestone

Comments

@brian-mann
Copy link
Member

@brian-mann brian-mann commented Mar 27, 2017

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:

zone_single_modal_edit_name_spec js-1

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
Copy link

@bsmithEG bsmithEG commented May 26, 2018

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
Copy link

@itaykotler-fundbox itaykotler-fundbox commented Aug 8, 2018

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

@jennifer-shehane
Copy link
Member

@jennifer-shehane jennifer-shehane commented Aug 13, 2018

@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
Copy link
Contributor

@lilaconlee lilaconlee commented Dec 4, 2018

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

Ordinal:
screen shot 2018-12-04 at 4 34 21 pm

Cardinal:
screen shot 2018-12-04 at 4 41 53 pm

Tooltip:
screen shot 2018-12-04 at 4 39 47 pm 2

Labels for stub:
screen shot 2018-12-04 at 4 42 37 pm
screen shot 2018-12-04 at 4 42 23 pm

@chrisbreiding
Copy link
Contributor

@chrisbreiding chrisbreiding commented Dec 5, 2018

/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
Copy link
Member

@jennifer-shehane jennifer-shehane commented Dec 5, 2018

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
Copy link
Contributor

@lilaconlee lilaconlee commented Dec 6, 2018

Some iteration, think I'm liking the first one so it keeps the visual relationship with the original stub.
screen shot 2018-12-06 at 10 50 15 am

screen shot 2018-12-06 at 10 27 03 am

@brian-mann
Copy link
Member Author

@brian-mann brian-mann commented Dec 7, 2018

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

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

img_8402

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
Copy link
Member Author

@brian-mann brian-mann commented Dec 7, 2018

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
Copy link
Contributor

@lilaconlee lilaconlee commented Dec 7, 2018

I'll do something more like this for now for when there are more than one
screen shot 2018-12-07 at 12 49 01 pm

@chrisbreiding chrisbreiding removed this from the Sprint 14 milestone Dec 10, 2018
@chrisbreiding chrisbreiding added this to the Sprint 15 milestone Dec 10, 2018
@lilaconlee
Copy link
Contributor

@lilaconlee lilaconlee commented Dec 17, 2018

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:
screen shot 2018-12-17 at 1 51 40 pm
With duplicates open:
screen shot 2018-12-17 at 1 52 32 pm

@lilaconlee lilaconlee removed this from the Sprint 15 milestone Jan 14, 2019
@lilaconlee lilaconlee added this to the Sprint 19 milestone Jan 14, 2019
chrisbreiding added a commit that referenced this issue Jan 18, 2019
- Fixes #477
@chrisbreiding
Copy link
Contributor

@chrisbreiding chrisbreiding commented Jan 18, 2019

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.

lilaconlee added a commit that referenced this issue Jan 22, 2019
- Fixes #477
chrisbreiding added a commit that referenced this issue Apr 10, 2019
* Update alias UI (#2960)

- Fixes #477

* fix reporter fixture name
laurinenas added a commit to laurinenas/cypress that referenced this issue Apr 28, 2019
* Update alias UI (cypress-io#2960)

- Fixes cypress-io#477

* fix reporter fixture name
@cypress-bot
Copy link

@cypress-bot cypress-bot bot commented May 17, 2019

Released in 3.3.0.

@danielclariondoor
Copy link

@danielclariondoor danielclariondoor commented May 24, 2019

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
Copy link

@strass strass commented Feb 18, 2020

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

@cypress-io cypress-io locked as resolved and limited conversation to collaborators Mar 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants