-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Navigation Block: Add tests for Nav block uncontrolled blocks dirty state checking #46329
Navigation Block: Add tests for Nav block uncontrolled blocks dirty state checking #46329
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Size Change: +10 B (0%) Total Size: 1.33 MB
ℹ️ View Unchanged
|
|
||
if ( ! isDeepEqual( x[ prop ], y[ prop ], shouldSkip ) ) | ||
return false; | ||
} else return false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this is the only line that's not tested here. Do we want to cover the case where if ( y.hasOwnProperty( prop ) )
isn't true?
I don't think we need 100% coverage though! These tests look great to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the recent commit should now address that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still seeing the same coverage with the latest commit, although if I move dropCap
to the first array, and add a different property to the second array, like this:
expect(
areBlocksDirty(
[ { name: 'core/paragraph' }, { dropCap: false } ],
[ { name: 'core/paragraph' }, { content: 'Some content' } ]
)
).toBe( true );
This is reported as 100% coverage. I think it's because we're looping through the properties on the first array to compare if they're in the second, so there needs to be at least one different property on the first array in order for it to jump into line 44.
The line is also covered if we just compare name
vs something else like content
on its own, but I guess name
will most likely always exist, so there's not much point in testing if that is different on its own, e.g.:
expect(
areBlocksDirty(
[ { name: 'core/paragraph' } ],
[ { content: 'core/paragraph' } ]
)
).toBe( true );
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mikachan Are you using a tool to check the coverage? Can you explain how I can debug this myself 🙏
Looks like this auto merged but you would of course be super welcome to raise a PR if you felt able.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, sure. I was running npm run test:unit are-blocks-dirty.js -- --coverage
.
I don't think getting to 100% is a big deal, but there was only this one line that wasn't covered here, so it's so close I thought we may as well cover it. I've created a quick PR: #46355
d778fc8
to
9cac88a
Compare
…dPress#46329) * Extract function and add basic tests * Augment the tests * Normalize test descriptors * Fix spelling * Add test for missing condition
What?
Adds unit tests for work done in #46223 and improves function naming.
Why?
This is a fragile point in the code and thus deserves some unit tests at least.
Also helps make the React component responsible for fewer things.
How?
Testing Instructions
Run through test steps in #46223 to check for regressions.
Also run tests
Testing Instructions for Keyboard
Screenshots or screencast