-
Notifications
You must be signed in to change notification settings - Fork 56
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
Conversation
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.
Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job! |
src/test/videopress/constants.js
Outdated
'Preload Metadata', | ||
]; | ||
|
||
export const PLAYBACK_BAR_COLOR_SETTINGS = [ 'Dynamic color' ]; |
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 plan to work on adding the color selections in a future PR.
9ee7b0b
to
b4bfd6d
Compare
'Preload Metadata', | ||
]; | ||
|
||
export const PLAYBACK_BAR_COLOR_SETTINGS = [ 'Dynamic color' ]; |
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 will be added to in an upcoming PR.
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.
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.
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.
Ah interesting, this will be also helpful for the upload test cases.
PLAYBACK_SETTINGS.forEach( ( setting ) => { | ||
it( `should update Playback Settings section's ${ setting } setting`, async () => { |
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.
Jest provides a function to run the same tests with different data, sharing here in case you want to use it.
src/test/videopress/edit.js
Outdated
let screen; | ||
|
||
beforeEach( async () => { | ||
// Arrange | ||
screen = await initializeBlockWithHTML(); | ||
|
||
await selectAndOpenBlockSettings( screen ); | ||
} ); |
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.
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.
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.
Happy to go with the standard here, updated in 77aa2c9.
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)
Discussion here: #5751 (comment)
@fluiddot thank you for the review 🙇♀️
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. |
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 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
src/test/videopress/edit.js
Outdated
jest.runOnlyPendingTimers(); | ||
|
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.
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() );
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.
Thank you, I've gone ahead to implement that in b0be14a.
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 🎊 !
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.
Thanks @fluiddot! I'll go ahead to merge as-is and address mocking |
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:
To test:
TEST_RN_PLATFORM=ios npm run test src/test/videopress/edit.js
andTEST_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: