Enable object as parameter for css, prop, and attr assertions #7356
Conversation
|
Thanks for the contribution! Below are some guidelines Cypress uses when doing PR reviews.
PR Review ChecklistIf any of the following requirements can't be met, leave a comment in the review selecting 'Request changes', otherwise 'Approve'. User Experience
Functionality
Maintainability
Quality
Internal
|
There was a problem hiding this comment.
1. Assertion display differences
The display of the assertions differs when you use Cypress .should() assertions versus the standard expect. When using .should() it always only displays the last assertion in the Command Log. You should be able to write tests around the number/value of logs displayed in this situation.
My code against <div style="display: block; position: absolute;">div</div>
it('visit', () => {
cy.visit('index.html')
cy.get('div').then(($div) => {
expect($div).to.have.css({ display: 'block' })
expect($div).to.have.css({ position: 'absolute' })
expect($div).to.have.css({ display: 'block', position: 'absolute' })
})
})
it('visit', () => {
cy.visit('index.html')
cy.get('div').should('have.css', { display: 'block' })
cy.get('div').should('have.css', { position: 'absolute' })
cy.get('div').should('have.css', { display: 'block', position: 'absolute' })
})
2. Empty object behavior
The assertions always pass when passed an empty Object. I dunno, maybe this is ok? Seems a bit weird though. The assertions don't display in the UI at all, so it seems like a noop.
it('visit', () => {
cy.visit('index.html')
cy.get('div').then(($div) => {
expect($div).to.have.css({})
})
})
it('visit', () => {
cy.visit('index.html')
cy.get('div').should('have.css', {})
})
packages/driver/test/cypress/integration/commands/assertions_spec.js
Outdated
Show resolved
Hide resolved
|
@chrisbreiding and I decided that its probably best to not make these changes as they are fairly inconsistent with other methods and the existing Chai api, plus there would have to be a unique workaround to fix the logging issues. For now, I'm just going to submit another PR that causes a test to fail when passed an object rather than blindly succeed. |
|
I am not convinced this should not be implemented... I don't believe there are logging issues with this. |
Co-authored-by: Ben Kucera <14625260+Bkucera@users.noreply.github.com>
|
Perhaps this illustrates the issue more clearly. When using @brian-mann Can you explain more clearly why you consider this not an issue?
Also, my second point about asserting on an empty object hasn't been responded to - whether this is desired behavior or not. |
|
With the object literal pattern - its really a "subset" kind of assertion, which means that the key's of the object are what you're asserting against - not the entirety of the derived CSS. An element may have 100 inherited styles, and the keys in the object are the things you're validating. Therefore, when given a blank object then I believe this would give you a specific error telling you to provide some kind of assertion otherwise there's nothing specifically we can assert about. |
… a command and the previous command in a hook was a cy.then
- capture the assertionId and pass it around as state - if the same underlying assertion is generating multiple chai assertions, then merge the new assertions on the existing log instead of generating multiple command logs
|
Closing due to inactivity. We can reopen a new PR if we feel the work is something we want to prioritize in the future. |
User facing changelog
Now have the option to pass an object of values to the
attr,prop, andcssassertion methods.Additional details
This change was needed because previously passing an object would always make the assertion pass. An exception could be thrown, but actually being able to pass an object would be a better option.
How has the user experience changed?
Take the following test for example:
The intended behavior is that groups 1 and 3 pass, while group 2 does not.
Before these changes, groups 1 and 2 would pass while group 3 would not. The screenshot also shows that the correct comparison was not being done:
After these changes, the correct comparisons are done and group 1 passes while group 2 does not. The screenshot shows how the correct comparison is used:
As intended, groups 1 and 3 both pass with the correct comparisons being done:
PR Tasks
cypress-documentation?type definitions?Docs changes: cypress-io/cypress-documentation#2803