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 · 14 comments

Comments

7 participants
@brian-mann
Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented Aug 8, 2018

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

@jennifer-shehane

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Contributor

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

@lilaconlee

This comment has been minimized.

Copy link
Contributor

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 modified the milestones: Sprint 15, Sprint 19 Jan 14, 2019

chrisbreiding added a commit that referenced this issue Jan 18, 2019

@chrisbreiding

This comment has been minimized.

Copy link
Collaborator

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

chrisbreiding added a commit that referenced this issue Apr 10, 2019

Update alias UI (#2960) (#3188)
* 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) (cypress-io#3188)
* Update alias UI (cypress-io#2960)

- Fixes cypress-io#477

* fix reporter fixture name
@cypress-bot

This comment has been minimized.

Copy link

commented May 17, 2019

Released in 3.3.0.

@danielclariondoor

This comment has been minimized.

Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.