Description

Fixes #29442.

Add extra logic to some of the native unit tests that renders blocks:

• Register the block as the editor does
• Create a function that returns the BlockEdit component that will render the block that we want to test

This way, by rendering the edit components from the BlockEdit component, we add the block edit context that could be required by other components when they're rendered.

In fact, this is the case when the incoming changes from this PR would be merged, the RichText editor component will require the clientID property that is exposed from a new context that is rendered in BlockEdit component.

Caveats

My initial approach was to apply this change to all the native unit tests that render edit components but didn't work.

For example in the File block, one of the tests triggers the onLayout handler. If we render the BlockEdit component, we don't have access to the instance required to trigger that handler so the test fails.

I spent some time on finding an alternative but I didn't find any that fits easily. One option I tried was using the enzyme library but when rendering the component via the mount function, AztecView generates multiple errors. Shallow rendering is not enough because the required handler that we want to trigger is in the children.

Probably the best option would be to integrate a more complete library like @testing-library/react-native, that provides a lot interesting functionality that would make easier to do native unit tests.

How has this been tested?

Test with latest changes from trunk branch

1. Run npm run native test.
2. Observe that all unit tests pass.

Test with changes from PR

1. Checkout branch try/block-context-cleanup from the PR.
2. Cherry-pick changes from this PR's commit without committing via the command git cherry-pick -n 742eb696556f87707aca0517656d7464ab543bdc.
3. Run npm run native test.
4. Observe that all unit tests pass.
5. Discard changes from the cherry-pick.

Screenshots

N/A

Types of changes

Bug fix

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.