allow for aliasing of things beside DOM elements

[jennifer-shehane]

I'd like to be able to alias things other than DOM elements, for example a url string of a request. example:

describe "asset search", ->
  beforeEach ->
   cy
     .route(/assets/, {}).as("getAssets")
     .get("form").submit()
     .wait("@getAssets").its("url").as("requestUrl")

   it "does not search areaId", ->
     cy.get("@requestUrl").should("not.match", /areaId/)

   it "does not search locationId", ->
     cy.get("@requestUrl").should("not.match", /locationId/)

This currently just says Syntax error, unrecognized expression: @requestUrl

[brandon-beacher]

Would assign work for this?

[jennifer-shehane]

Yes, .assign() would work for this. Wanted @brian-mann to just look over to decide if .as() should be extended to accommodate for this or not.

[brian-mann]

Yah that's what I talked to Jennifer about when she brought up this issue. Should I extend cy.get to alias any object or primitive, or only allow it as glue between command relationships. I'm not sure yet. This is the use case I imagined for cy.assign.

There are still advantages to cy.assign but you would see its usefulness go down by extending cy.get. This biggest disadvantage of cy.assign is that its difficult to get this into a cy chain. However the cy.wrap command is coming soon which takes any existing value and allows you to chain off of it.

The above example would look like this using cy.assign

describe "asset search", ->
  beforeEach ->
   cy
     .route(/assets/, {}).as("getAssets")
     .get("form").submit()
     .wait("@getAssets").its("url").assign("requestUrl")

   it "does not search areaId", ->
     expect(@requestUrl).not.to.match(/areaId/)

   it "does not search locationId", ->
     expect(@requestUrl).not.to.match(/locationId/)

With cy.wrap coming soon it could be changed to:

describe "asset search", ->
  beforeEach ->
   cy
     .route(/assets/, {}).as("getAssets")
     .get("form").submit()
     .wait("@getAssets").its("url").assign("requestUrl")

   it "does not search areaId", ->
     cy.wrap(@requestUrl).should("not.match", /areaId/)

   it "does not search locationId", ->
     cy.wrap(@requestUrl).should("not.match", /locationId/)

Both are functionally equivalent. I would say that all users will at some point use aliasing, since it has a much broader use case. I wouldn't say however that all users will use assign. If that assumption is true, instead of introducing 2 commands (at least) to handle assigning, it might make more sense to expand aliasing to accommodate all values.

I don't know yet I'll keep coming up with examples and make a decision after I see more situations.

[brian-mann]

This has been implemented in 0.5.8.

cy.assign has been removed, and has been folded into cy.as.

In other words, cy.as does what cy.assign did automatically now.