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

VideoPress block: Initial setting tests #5751

Merged
merged 29 commits into from
May 15, 2023
Merged

Conversation

SiobhyB
Copy link
Contributor

@SiobhyB SiobhyB commented May 10, 2023

Part of the coverage efforts outlined in #5734

Description

The changes in this PR introduce tests that ensure the VideoPress block's title, description, and Playback settings can be successfully updated, as well as some of the settings in the Playback Bar Color and Privacy and Rating panels.

Note, the following are not covered by this PR, and will be worked on in separate PRs:

  • Rating and Privacy picker selection.
  • Various color selections for Playback Bar Color.
  • Setting synchronization between the app and the web.

To test:

  • Verify the HTML in the snapshot file matches with the reality of what the block's HTML would look after making the relevant changes.
  • Run the TEST_RN_PLATFORM=ios npm run test src/test/videopress/edit.js and TEST_RN_PLATFORM=android npm run test src/test/videopress/edit.js commands from the terminal to verify the tests pass as expected. Also, verify the tests on this PR pass.

PR submission checklist:

  • I have considered adding unit tests where possible.
  • I have considered if this change warrants user-facing release notes more info and have added them to RELEASE-NOTES.txt if necessary.

Siobhan added 9 commits May 10, 2023 09:10
This commit introduces a set of constants related to the VideoPress block settings, including default props, block HTML, playback settings, color settings, rating options, privacy options, and additional settings. These constants will be used to manage and manipulate VideoPress block properties in a more organised and maintainable manner.
This commit contains the code necessary to initialize the editor with existing HTML and open the block's settings. It serves as the groundwork for future tests, which will actually change the block's settings.
@SiobhyB SiobhyB self-assigned this May 10, 2023
@SiobhyB SiobhyB added Testing Anything related to automated tests VideoPress block labels May 10, 2023
@peril-wordpress-mobile
Copy link

peril-wordpress-mobile bot commented May 10, 2023

Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job!

src/test/videopress/edit.js Outdated Show resolved Hide resolved
'Preload Metadata',
];

export const PLAYBACK_BAR_COLOR_SETTINGS = [ 'Dynamic color' ];
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 plan to work on adding the color selections in a future PR.

@SiobhyB SiobhyB force-pushed the add/videopress-setting-tests branch 2 times, most recently from 9ee7b0b to b4bfd6d Compare May 10, 2023 11:15
'Preload Metadata',
];

export const PLAYBACK_BAR_COLOR_SETTINGS = [ 'Dynamic color' ];
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This will be added to in an upcoming PR.

@SiobhyB SiobhyB marked this pull request as ready for review May 10, 2023 11:34
@SiobhyB SiobhyB requested review from jhnstn and fluiddot May 10, 2023 11:35
Copy link
Contributor

@fluiddot fluiddot left a comment

Choose a reason for hiding this comment

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

When running the tests I got several warnings with the following message

Warning: An update to Player inside a test was not wrapped in act(...).

    When testing, code that causes React state updates should be wrapped into act(...):

    act(() => {
      /* fire events that update state */
    });

Seems the player component is being updated after executing some of the actions. It would be great to incorporate a check for this in the test cases to avoid the warning.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah interesting, this will be also helpful for the upload test cases.

src/test/videopress/local-helpers/utils.js Outdated Show resolved Hide resolved
src/test/videopress/edit.js Outdated Show resolved Hide resolved
Comment on lines +103 to +104
PLAYBACK_SETTINGS.forEach( ( setting ) => {
it( `should update Playback Settings section's ${ setting } setting`, async () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Jest provides a function to run the same tests with different data, sharing here in case you want to use it.

Comment on lines 61 to 68
let screen;

beforeEach( async () => {
// Arrange
screen = await initializeBlockWithHTML();

await selectAndOpenBlockSettings( screen );
} );
Copy link
Contributor

Choose a reason for hiding this comment

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

Nitpick: Usually in integration tests, we have all the arrange, act, and expectation parts contained within the it function. This introduces a bit of redundancy but in general, helps readability as you can see in the same place what the test case is doing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Happy to go with the standard here, updated in 77aa2c9.

Siobhan added 5 commits May 10, 2023 17:33
This addresses the feedback received here: #5751 (review)
Refactored following feedback here: #5751 (comment)
As per this feedback, this introduces redundancy, but is a tradeoff for readability: #5751 (comment)
@SiobhyB
Copy link
Contributor Author

SiobhyB commented May 10, 2023

@fluiddot thank you for the review 🙇‍♀️

Seems the player component is being updated after executing some of the actions. It would be great to incorporate a check for this in the test cases to avoid the warning.

I've gone ahead to address this in 881272b, and believe I've addressed your other feedback too. Let me know if there's anything else that needs improving here.

Copy link
Contributor

@fluiddot fluiddot left a comment

Choose a reason for hiding this comment

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

I noticed several logs with the following message when running the tests. Seems the block is trying to fetch the metadata via fetchVideoItem function but fails. If we don't need that data for these tests, maybe we could mock that function, WDYT?

videopress:lib:fetch-video-item updating retry from 0 to 1

Comment on lines 48 to 49
jest.runOnlyPendingTimers();

Copy link
Contributor

Choose a reason for hiding this comment

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

When running the command TEST_RN_PLATFORM=ios npm run test src/test/videopress/edit.js I'm getting the following warning:

 A function to advance timers was called but the timers APIs are not mocked with fake timers. Call `jest.useFakeTimers({legacyFakeTimers: true})` in this test file or enable fake timers for all tests by setting {'enableGlobally': true, 'legacyFakeTimers': true} in Jest configuration file.
    Stack Trace:

          46 | 		await addBlock( screen, 'VideoPress' );
          47 |
        > 48 | 		jest.runOnlyPendingTimers();
             | 		     ^
          49 |
          50 | 		// Get block
          51 | 		const videoPressBlock = await getBlock( screen, 'VideoPress' );

          Error:
          at FakeTimers._checkFakeTimers (node_modules/@jest/fake-timers/build/legacyFakeTimers.js:394:13)
          at FakeTimers.runOnlyPendingTimers (node_modules/@jest/fake-timers/build/legacyFakeTimers.js:189:10)
          at Object.runOnlyPendingTimers (src/test/videopress/edit.js:48:8)
          at asyncGeneratorStep (node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24)
          at _next (node_modules/@babel/runtime/helpers/asyncToGenerator.js:25:9)
          at tryCallOne (gutenberg/node_modules/promise/lib/core.js:37:12)
          at gutenberg/node_modules/promise/lib/core.js:123:15
          at flush (gutenberg/node_modules/asap/raw.js:50:29)

Probably we could use the withFakeTimers helper to address the issue:

// When the block is inserted, it automatically opens the media picker.
// On iOS, this picker is displayed using a timer, so we need to run it
// to allow any DOM update.
await withFakeTimers( () => jest.runOnlyPendingTimers() );

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you, I've gone ahead to implement that in b0be14a.

@SiobhyB SiobhyB requested a review from fluiddot May 11, 2023 18:22
Copy link
Contributor

@fluiddot fluiddot left a comment

Choose a reason for hiding this comment

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

LGTM 🎊 !

I confirmed that all tests passed ✅ . Not a blocker, but we might consider adding the mock I suggested here to avoid the fetch failures when the block tries to sync the metadata.

@SiobhyB
Copy link
Contributor Author

SiobhyB commented May 15, 2023

Thanks @fluiddot! I'll go ahead to merge as-is and address mocking fetchVideoItem as part of a separate PR. 🙇‍♀️

@SiobhyB SiobhyB merged commit 9360b7d into trunk May 15, 2023
@SiobhyB SiobhyB deleted the add/videopress-setting-tests branch May 15, 2023 09:55
@fluiddot fluiddot mentioned this pull request May 26, 2023
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Testing Anything related to automated tests VideoPress block
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants