The previous warning is no longer shown when running the tests, seems that now a different one is displayed instead.

These new a11y values have been added in RN 0.71 (reference).

This fixes a failure I encountered when running the tests. The error was related to missing the option "Insert from URL" on the Image and Audio block.

After reviewing the logic of MediaUpload component, seems the error is legit, as the URL insertion option is only available when passing the onSelectURL prop. Now I'm curious about how these tests passed before 🤔 .

https://github.com/WordPress/gutenberg/blob/b52d61ed6c1307e9ccf0eedaddafe52c06033dbd/packages/block-editor/src/components/media-upload/index.native.js#L138C24-L145

The link suggestions are fetched using debounce. Since we are not testing the suggestions in this test suites, I disabled debounce to avoid belated state updates.

I noticed that the Link picker component is making requests to fetch the link suggestions. This was causing a failure in the tests because, although apiFetch is mocked, it's not returning a promise. This logic is not being tested in these test suites, so I simply mock it.

This HTML has been updated as its format was outdated.

I suppose this is a good example of the benefit of leveraging UI instead of initial HTML. I wonder if there is are benefits to relying upon initial HTML. Test speed possibly? I'm unsure of if the impact is negligible.

I think the cases where we use initial HTML are mainly driven to start the editor in a specific state, similar to opening a post with content. This has the downside of using fixed versions of the block's HTML code, which as in this case, it would eventually lead to being outdated.

It's likely that adding the block and setting the content is slower than using the initial HTML. I haven't reviewed thoroughly these test cases to determine if could use a different approach, my main goal in this PR was to simply fix the issues to unblock the RN upgrade. Nevertheless, we could improve this in another PR if we feel the need to.

I haven't reviewed thoroughly these test cases to determine if could use a different approach, my main goal in this PR was to simply fix the issues to unblock the RN upgrade. Nevertheless, we could improve this in another PR if we feel the need to.

Definitely. No intention from my side to modify the testing approach in this PR. Merely shared the thought for general consideration.

This patch is no longer necessary as @react-navigation/native has been updated to 6.x (reference).

This patch replaces the one made for the previous version of react-devtools-core (https://github.com/WordPress/gutenberg/pull/51303/files#diff-efdeee0f12bb2896ff685c25c7b899da1f11686b6d333de8c33265db624b870e).

I am hesitant to await this nuanced UI logic in a test helper. This feels like something that should be accounted for within the Columns test file.

I am unaware of a specific example right now, but I could see abstracting the timers to this top-level helper confusing future test writers. E.g. if my subject block transitions from one state to another over a period of time, i.e. with setTimeout, this global helper would prevent me from asserting (or simply understanding and recognizing) that transition.

Are there act examples outside of the Column block of which you are aware? Does it make sense to relocate this to the block tests that need it?

I haven't checked if other blocks use timers to update their local state when created. I agree that, if this is only needed for a specific block, we could execute in the associated test files instead of in a generic way.

My purpose with this approach was to simplify the block insertion, as I feel that it won't be very common to assert potential state updates that happen during the insertion. I assumed that all of them acted as part of the addBlock helper. However, in case we need to, we could run the timers conditionally via a configuration parameter.

I'll check if this is needed in more blocks, and depending on that, we could decide if we rather run the timers generally here or in each test 👍 .

Your expressed purpose makes a lot of sense. I recognize that our testing environment needs to find a balance between convenience and comprehensibility.

To be clear, I am not opposed to inserting this global timer into the addBlock helper. I merely wanted to note its potential for breeding confusion due to the obscure nature of this timers run. The inline comments will likely help to mitigate that, provided the test author reads the source of addBlock when using it.

Please feel free to leave this implementation as-is. A configuration parameter could arguably be unnecessary complexity.

From reviewing the example inner block state changes, it makes sense to abstract this microtask flush, from my perspective.

The changing state is already abstract, not incredibly block-specific, and does not always result in changes that are queryable in the UI.

Was populating the text via the link URL causing issue or done merely for clear presentation?

I suppose this is a good example of the benefit of leveraging UI instead of initial HTML. I wonder if there is are benefits to relying upon initial HTML. Test speed possibly? I'm unsure of if the impact is negligible.