-
Notifications
You must be signed in to change notification settings - Fork 58
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
Fix VideoPress block test cases #5916
Fix VideoPress block test cases #5916
Conversation
Instead of using a constant for the block HTML, now we generate the HTML via the `generateBlockHTML` util.
This is needed to keep the same block attributes set via the block HTML generation. Extract fetch mock metadata to a constant
The only change is that the video is now public when setting a caption. This has no impact in the testing logic.
src/test/videopress/edit.js
Outdated
post_id: 1, | ||
duration: 2803, |
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.
These parameters are not really being tested but decided to include them to avoid updating the Jest snapshots. Especially, as updating snapshots usually makes the changes harder to review.
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 have no objections to reviewing a snapshot change if it means the stored snapshot is more helpful or realistic. However, if these mocked parameters achieve a more realistic picture, then it makes sense to keep them IMO.
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.
To be honest, these parameters don't provide any value in the snapshot. They aren't meant to be updated in the test cases but since the VideoPress block updates settings automatically from the API when rendering the block, they are included. I'm happy with both options, but if including them in the tests gives a wrong impression of their usage, I can revert it.
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 have no strong preference. I suppose I mostly wanted to convey that we should not be afraid of updating snapshots. If a given snapshot is too unwieldily to review, a more appropriate alternative may be forgoing snapshots altogether and asserting against specific outcomes, e.g. attributes within the snapshot.
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 have no strong preference. I suppose I mostly wanted to convey that we should not be afraid of updating snapshots.
Yep, I think in this case we can update the snapshots as we don't have that many to make the review complex 👍.
If a given snapshot is too unwieldily to review, a more appropriate alternative may be forgoing snapshots altogether and asserting against specific outcomes, e.g. attributes within the snapshot.
Good point. In general, I'd rather lean on snapshots to simplify test logic. But I agree that in some cases there's a good value on asserting specific outcomes. For these test cases, I'm hesitant about which one would fit better. For now, I'd prefer to keep them as-is and only focus on the fixes, if that makes sense.
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.
For now, I'd prefer to keep them as-is and only focus on the fixes, if that makes sense.
Absolutely. 🚀
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've just applied this suggestion via 68a1ccd.
{ | ||
request: { | ||
path: `/wpcom/v2/videopress/${ guid }/check-ownership/${ postID }`, | ||
method: 'GET', | ||
}, | ||
response: { | ||
'video-belong-to-site': belongsToSite, | ||
}, | ||
}, |
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.
We need to mock this response, otherwise, some of the block settings like the title will be locked.
src/test/videopress/edit.js
Outdated
post_id: 1, | ||
duration: 2803, |
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 have no objections to reviewing a snapshot change if it means the stored snapshot is more helpful or realistic. However, if these mocked parameters achieve a more realistic picture, then it makes sense to keep them IMO.
Fixes the JSDoc type of `isVideoPrivate` and `isSitePrivate` params. Co-authored-by: David Calhoun <[email protected]>
Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job! |
@@ -1,39 +1,39 @@ | |||
// Jest Snapshot v1, https://goo.gl/fbAQLP | |||
|
|||
exports[`Update VideoPress block's settings should update Playback Bar Color section's Dynamic color setting 1`] = `"<!-- wp:videopress/video {"title":"default-title-is-file-name","description":"","id":1,"guid":"AbCdEfGh","privacySetting":2,"allowDownload":false,"rating":"G","isPrivate":true,"duration":2803} /-->"`; | |||
exports[`Update VideoPress block's settings should update Playback Bar Color section's Dynamic color setting 1`] = `"<!-- wp:videopress/video {"title":"default-title-is-file-name","description":"","id":34,"guid":"AbCdEfGh","privacySetting":2,"allowDownload":false,"rating":"G","isPrivate":true,"duration":1200} /-->"`; |
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.
The id
and duration
attributes have been modified due to using the default values specified in the util function (reference). They don't have an impact on the test cases, so we can omit them.
gutenberg-mobile/src/test/videopress/local-helpers/utils.js
Lines 203 to 229 in 68a1ccd
const postID = metadata?.post_id ?? 34; | |
return [ | |
{ | |
request: { | |
path: `/wpcom/v2/media/videopress-playback-jwt/${ guid }`, | |
method: 'POST', | |
body: {}, | |
}, | |
response: { | |
metadata_token: token, | |
}, | |
}, | |
{ | |
request: { | |
path: isPrivate | |
? `/rest/v1.1/videos/${ guid }?metadata_token=${ token }` | |
: `/rest/v1.1/videos/${ guid }`, | |
credentials: 'omit', | |
global: true, | |
}, | |
response: { | |
description: 'video-description', | |
post_id: postID, | |
guid, | |
private_enabled_for_site: false, | |
title: 'video-title', | |
duration: 1200, |
} | ||
return { | ||
privacySetting: isVideoPrivate ? 1 : 0, | ||
isPrivate, |
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.
Sorry I didn't notice before 🤦 , but this should be:
isPrivate: isVideoPrivate,
I'll push a fix directly in the base branch (4349216) 💨
This PR aims to fix the failures in #5874 related to unit tests.
ci/circleci: Test Android
ci/circleci: Test iOS
We could omit the rest as they will be solved in other PRs.
To test:
npm run test
.Alternatively, we could rely on the CI job that runs the unit tests.
PR submission checklist: