-
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
Add tests for the BlockSwitcher component. #990
Conversation
250b744
to
8de49b9
Compare
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.
Those tests need to be updated to work with Jest. We no longer use chai and sinon. @BE-Webdesign, let me know if I should help you with it.
Hi Grzegors, Thank you for the information and offer to help. I would be glad to revise this to Jest and use snapshots instead. Are we switching back off of Jest though (#2757)? I don't want to revise something that might be reverted. |
I think we are going to stay with Jest after very surprising announcement from Facebook about relicensing under the MIT license :) In that case I recommend using jest-codemods to update tests. It should work out of the box for everything but Sinon spy. I used those codemods when updating code to work with Jest API, it's amazing! |
Sinon support is being worked on in jest-codemods project, see skovhus/jest-codemods#68 - now with your code examples :) |
I'm afraid it might be very difficult to make those test work since |
8de49b9
to
429fb42
Compare
</div> | ||
`; | ||
|
||
exports[`BlockSwitcher Test block switcher with multi block of different types. 1`] = `null`; |
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.
If it renders nothing, you can simply assert the following:
expect( wrapper.html() ).toBe( null );
when using enzyme
to avoid creating snapshot for such test.
See
it( 'should not render when no heading blocks provided', () => { |
block, | ||
]; | ||
|
||
const tree = renderer |
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.
This way is promoted by Jest team in their official docs. I personally prefer using enzyme
to test React components, but this it might be an easier way in case when you have only snapshot tests in the file. Enzyme is more helpful when doing more complex checks.
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.
Yeah, Enzyme is great for getting into the details. Not sure, how we want to use snapshots etc.
7e191a4
to
167d1be
Compare
|
||
describe( 'mapStateToProps', () => { | ||
test( 'should return the expected selected block uids and whether there is a multiselection.', () => { | ||
//const isMultiBlockSelection = 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.
Obsolete comment, should be removed.
}, | ||
}; | ||
const expected = { | ||
isMultiBlockSelection: selectedBlockUids.length > 1, |
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 would read better to have explicit value here instead.
expect( MultiBlocksSwitcher( { isMultiBlockSelection, selectedBlockUids } ) ).toMatchSnapshot(); | ||
} ); | ||
|
||
describe( 'mapStateToProps', () => { |
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.
That's interesting, it seems like a good idea to test this, too 👍
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 kind of disagree with this, I dislike the fact that we export these functions for test purpose. In general if the behavior of these functions is complex enough to deserve a test, it's complex enough to deserve a selector :)
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.
Would using mock stores be preferable?
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.
No, just testing the wrapped component instead and providing the right props. That's what we do for most components.
*/ | ||
import { MultiBlocksSwitcher, mapStateToProps } from '../multi-blocks-switcher'; | ||
|
||
describe( 'MultiBlocksSwitcher', () => { |
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.
This test suite is excellent. This is exactly what we need 👍
|
||
expect( dispatch ).toHaveBeenCalled(); | ||
|
||
/** |
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.
This comment should be removed.
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.
Ooops. 🙃
describe( 'mapStateToProps', () => { | ||
test( 'should return an object containing the blocks list as a blocks prop.', () => { | ||
const blocks = [ | ||
{ |
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.
Can we move this block to it's own variable to avoid repetition in state
?
} ); | ||
|
||
test( 'Test block switcher with multi block of different types.', () => { | ||
const block1 = { |
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.
Can we move those blocks level up and reuse in other tests to avoid code duplication? We can also give them names like headingBlock
and paragraphBlock
if that is relevant.
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 would have to double check, but I am pretty sure that would work.
/> | ||
`; | ||
|
||
exports[`BlockSwitcher Test block switcher with multi block of different types. 1`] = `""`; |
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.
According to this snapshots 3 tests don't render anything. It would read better to check against null
in the test instead.
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.
Yup, I need to look back through this to update.
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 left some comments. Lots of lines added here. I proposed some refactoring to avoid some code duplication.
a9b6619
to
3b58b63
Compare
Okay, much more condensed now. Not at 100% coverage, but close enough, this can be touched up again later, when all of the other components have a higher coverage ratio. |
Can we test the BlockSwitcher component UI only (like other components). I'd be happy to merge this PR if it's the case :) |
3b58b63
to
9d7197d
Compare
Updated with the latest changes in the master branch
@youknowriad removed all non UI related tests. |
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.
This is good to go 👍
Thanks @BE-Webdesign for working on this one. Sorry, it took so long to get it merged. |
These tests are related to progress on #641. They handle all instance
methods and any conditional rendering logic.
Testing Instructions
Verify that registering of blocks is indeed cleaned up and that tests
pass.