Thanks for the PR! I have some questions about the motivation:

people may set up their test env with pre-published pages containing blocks they wish to test.

I didn't imagine the utils would be used in this way. That's why we clear all posts/pages before starting the tests to guarantee a consistent testing environment. Under such an assumption, I would imagine the API to be implemented and used as the following instead:

const postContent = await fs.readFile( './my/test/post.html' );
const { id: postId } = await requestUtils.createPost( {
  title: 'My test post',
  content: postContent,
  status: 'publish',
} );
await admin.visitPostById( postId );

This ensures the post we're interacting with is always an isolated post that can't be intercepted by other parallel tests. It also enables full parallel testing in the future for more speed. It's also a lot faster because we don't have to visit the post list page to search for something by its title. The test is also portable since we just need the html file somewhere and don't need the post to exist in the database.

Most of the API are already supported. IIRC, we only need to implement visitPostById, which can also be inlined by replacing it with await admin.visitAdminPage( 'post.php', `post=${postId}&action=edit` ).

WDYT of this approach?

hi @kevin940726 thanks for the review and your patience while I responded!

I would imagine the API to be implemented and used as the following instead:

const postContent = await fs.readFile( './my/test/post.html' );
const { id: postId } = await requestUtils.createPost( {
  title: 'My test post',
  content: postContent,
  status: 'publish',
} );
await admin.visitPostById( postId );

ah this is a great idea, I see what you mean, I agree with all the reasons you mention about parallel testing too, thanks for the insight.

Most of the API are already supported. IIRC, we only need to implement visitPostById, which can also be inlined by replacing it with await admin.visitAdminPage( 'post.php', post=${postId}&action=edit ).

Would it make sense to create visitPostById in that case if it can easily be inlined? I wouldn't mind closing this PR as I don't feel visitPostById adds much value.

Please let me know if closing is your preference.