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

Add tests for the BlockSwitcher component. #990

Merged
merged 3 commits into from
Mar 8, 2018

Conversation

BE-Webdesign
Copy link
Contributor

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.

@BE-Webdesign BE-Webdesign added the [Type] Automated Testing Testing infrastructure changes impacting the execution of end-to-end (E2E) and/or unit tests. label Jun 2, 2017
@BE-Webdesign BE-Webdesign force-pushed the add/test/editor/block-switcher branch from 250b744 to 8de49b9 Compare June 14, 2017 16:41
gziolo
gziolo previously requested changes Sep 22, 2017
Copy link
Member

@gziolo gziolo left a 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.

@BE-Webdesign
Copy link
Contributor Author

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.

@gziolo
Copy link
Member

gziolo commented Sep 25, 2017

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!

@gziolo
Copy link
Member

gziolo commented Sep 25, 2017

Sinon support is being worked on in jest-codemods project, see skovhus/jest-codemods#68 - now with your code examples :)

@gziolo
Copy link
Member

gziolo commented Nov 13, 2017

I'm afraid it might be very difficult to make those test work since <BlockSwitcher /> was refactored to be a functional component that uses <Dropdown /> component and works with multiple blocks, not only one as before. I still think it would be a very beneficial to have this logic covered with tests. @youknowriad what is your take on this as you have been involved with the work on <Dropdown /> reusable component?

</div>
`;

exports[`BlockSwitcher Test block switcher with multi block of different types. 1`] = `null`;
Copy link
Member

@gziolo gziolo Dec 4, 2017

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', () => {
for reference.

block,
];

const tree = renderer
Copy link
Member

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.

Copy link
Contributor Author

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.

@gziolo gziolo dismissed their stale review December 4, 2017 07:58

It has new iterations


describe( 'mapStateToProps', () => {
test( 'should return the expected selected block uids and whether there is a multiselection.', () => {
//const isMultiBlockSelection = true;
Copy link
Member

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,
Copy link
Member

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', () => {
Copy link
Member

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 👍

Copy link
Contributor

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 :)

Copy link
Contributor Author

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?

Copy link
Contributor

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', () => {
Copy link
Member

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();

/**
Copy link
Member

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.

Copy link
Contributor Author

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 = [
{
Copy link
Member

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 = {
Copy link
Member

@gziolo gziolo Dec 8, 2017

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.

Copy link
Contributor Author

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`] = `""`;
Copy link
Member

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.

Copy link
Contributor Author

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.

gziolo
gziolo previously requested changes Dec 8, 2017
Copy link
Member

@gziolo gziolo left a 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.

@BE-Webdesign BE-Webdesign force-pushed the add/test/editor/block-switcher branch 2 times, most recently from a9b6619 to 3b58b63 Compare December 8, 2017 19:27
@BE-Webdesign
Copy link
Contributor Author

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.

@youknowriad
Copy link
Contributor

Can we test the BlockSwitcher component UI only (like other components). I'd be happy to merge this PR if it's the case :)

@gziolo gziolo force-pushed the add/test/editor/block-switcher branch from 3b58b63 to 9d7197d Compare March 8, 2018 09:34
@gziolo gziolo dismissed their stale review March 8, 2018 09:52

Updated with the latest changes in the master branch

@gziolo
Copy link
Member

gziolo commented Mar 8, 2018

@youknowriad removed all non UI related tests.

Copy link
Member

@gziolo gziolo left a 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 👍

@gziolo gziolo merged commit 107b0a7 into master Mar 8, 2018
@gziolo gziolo deleted the add/test/editor/block-switcher branch March 8, 2018 09:54
@gziolo
Copy link
Member

gziolo commented Mar 8, 2018

Thanks @BE-Webdesign for working on this one. Sorry, it took so long to get it merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Automated Testing Testing infrastructure changes impacting the execution of end-to-end (E2E) and/or unit tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants