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 to withFocusReturn HOC. #931

Merged
merged 2 commits into from
Jun 1, 2017

Conversation

BE-Webdesign
Copy link
Contributor

Adds basic withFocusReturn HOCtests. Covers cases dealing with the
handling of the focus. Related to progress on #641. Adds an extra
conditional to match if the body is focused the active elment should
become the one bound to the HOC, this is necessary as in the HTML DOM
spec it is not supposed to be possible to have ! document.activeElement ever be true.

Testing Instructions
Run npm i && npm run test-unit ensure tests pass. Change Dashicon logic
to ensure tests fail as they should. Verify disposable focus returning
still works.

@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 May 29, 2017
expect( wrappedElementShallow.text() ).to.equal( 'Testing' );
} );

it( 'passing additonal props', () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: additonaladditional

@nylen
Copy link
Member

nylen commented May 30, 2017

I'd clean up the test assertion messages a bit, as I'll note inline next to each one.

}

describe( 'withFocusReturn()', () => {
describe( 'expected behavior', () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this second describe block? Our tests are all testing "expected behavior" after all.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do see that the other PRs include multiple 2nd-level describe blocks though, so this is probably fine.

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, I tried to mirror other examples as best as I could. Probably did a bad job lol.

activeElement.blur();
} );

it( 'rendering with a basic <div> element', () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it renders with a basic...

expect( wrappedElement.node.props.test ).to.equal( 'test' );
} );

it( 'when component mounts and unmounts', () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it should do [something] when component mounts and unmounts

expect( document.activeElement ).to.equal( switchFocusTo );
} );

it( 'should return focus to element associated with HOC', () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one reads well 👍

@@ -23,7 +23,7 @@ function withFocusReturn( WrappedComponent ) {
if (
this.activeElement && (
( document.activeElement && wrapper && wrapper.contains( document.activeElement ) ) ||
! document.activeElement
( ! document.activeElement || document.body === document.activeElement )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case I wonder if we need ! document.activeElement at all?

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, there might be some possibility of this existing somehow, at one point JSDOM would not handle this to the HTML spec, so ! document.activeElement would be falsy. I think keeping it in is okay. Adds to the readability a bit in my opinion as well.

Adds basic withFocusReturn HOCtests. Covers cases dealing with the
handling of the focus. Related to progress on #641.  Adds an extra
conditional to match if the body is focused the active elment should
become the one bound to the HOC, this is necessary as in the HTML DOM
spec it is not supposed to be possible to have `!
document.activeElement` ever be true.

Testing Instructions
Run npm i && npm run test-unit ensure tests pass. Change Dashicon logic
to ensure tests fail as they should.  Verify disposable focus returning
still works.
@BE-Webdesign BE-Webdesign force-pushed the add/test/components/higher-order branch from 861e7c0 to 1e4ff65 Compare May 30, 2017 15:27
@BE-Webdesign
Copy link
Contributor Author

@nylen

Updated this. Let me know what you think of the conventions now.

Copy link
Member

@nylen nylen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@BE-Webdesign BE-Webdesign merged commit fc60e2f into master Jun 1, 2017
@BE-Webdesign BE-Webdesign deleted the add/test/components/higher-order branch June 1, 2017 21:54
aduth added a commit that referenced this pull request Mar 13, 2018
Existed prior to refactoring to track events (#2321, #931).

Causes conflict where intentional tabs away from the mounted element would revert focus back to the element (twice tab to dismiss a tooltip'd element)
aduth added a commit that referenced this pull request Mar 16, 2018
Existed prior to refactoring to track events (#2321, #931).

Causes conflict where intentional tabs away from the mounted element would revert focus back to the element (twice tab to dismiss a tooltip'd element)
aduth added a commit that referenced this pull request Mar 21, 2018
Existed prior to refactoring to track events (#2321, #931).

Causes conflict where intentional tabs away from the mounted element would revert focus back to the element (twice tab to dismiss a tooltip'd element)
aduth added a commit that referenced this pull request Mar 26, 2018
Existed prior to refactoring to track events (#2321, #931).

Causes conflict where intentional tabs away from the mounted element would revert focus back to the element (twice tab to dismiss a tooltip'd element)
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.

2 participants