TIL! neat

Same. Turns out reading the docs is useful 😆

Nit: This technique assumes the structure of the button to be a direct child of the row, which might change as an implementation detail? I would probably refactor this to select the row instead in the first place:

const firstMenuRow = page.getByRole( 'row' )
  .filter({ has: firstMenuItem });

const firstItemOptions = firstMenuRow
  .getByRole( 'button', {
    name: 'Options for Page Link block',
  } );

Isn't critical though!

For whatever reason that didn't work. It ended up producing

getByRole( 'treegrid', { name: 'Block navigation structure' } )
	.getByRole( 'row' )
	.filter( {
		has: getByRole( 'treegrid', { name: 'Block navigation structure' } )
			.getByRole( 'gridcell', { name: 'Page Link link' } )
			.filter( { hasText: 'Block 1 of 2, Level 1' } ),
	} )
	.getByRole( 'button', { name: 'Options for Page Link block' } );

I tried to find a different way to target this to avoid the CSS selector but I couldn't :S

Nope. There isn't a way which probably points to a flaw in the markup of the component. It's due an a11y review as part of #49091

maybe add a comment referring that PR so we can update the test once that gets merged?

I'm not sure there's an issue with the markup. It's a tricky one to solve.

You could possibly do something like this pseudocode:

const expectedPageTitle = 'My sample page';
await linkControl.search( expectedPageTitle );
await linkControl.selectOption( expectedPageTitle );
await expect( listView ).toHaveBlock( expectedPageTitle );

Have the test select a known page title, rather than trying to read the text from the option.

It might also be good to assert that the URL added is correct.

I would agree with @MaggieCabrera to add a comment referencing that PR, but it's non-blocking 👍 .

Have the test select a known page title, rather than trying to read the text from the option.

That might be better.

Only thing is if we ever change the implementation of "Recently Added" results in Link UI the test would start failing.

That's why I wanted to get the first result's text. I can extract to a helper on the utility class if that helps.

I added a getSearchResultText method to the LinkControl test util class.

In most frameworks test is just an alias for it, so the word it doesn't need to be in the description itself. I always think removing the word 'should' makes the description shorter and easier to read, so also suggesting that.

Maybe I should add some of this to the docs.

✅

This is really nice. I wonder if there's a way to ensure that the blocks are in the right order, maybe by selecting an nth row in the table as part of the selector.

It might also be good to port some of these tests over to the main List View once this PR is in, perhaps with groups and other blocks.

I wonder if there's a way to ensure that the blocks are in the right order, maybe by selecting an nth row in the table as part of the selector.

The tricky part is getting a list of gridcells for the blocks but not including other gridcells. If you have that then you can do nth() and assert on that.

I spent far too long trying to do that with @kevin940726 yesterday so ended up settling on this route.

This is pretty cool!

For some of these operations that are a bit more complex, it might help to include a utility class in the test file. Possibly one for LinkControl and one for ListView itself.

There's an example here:

And here's where it gets configured:

I think it could also be worth considering moving the block's List View tests into a separate file to keep things tidy.

I haven't made any utilities yet. Curious to try that.

I made one for Link Control.

and one for ListView itself.

I decided this was too much for this PR. Going to do a follow up.

I'm not sure there's an issue with the markup. It's a tricky one to solve.

You could possibly do something like this pseudocode:

const expectedPageTitle = 'My sample page';
await linkControl.search( expectedPageTitle );
await linkControl.selectOption( expectedPageTitle );
await expect( listView ).toHaveBlock( expectedPageTitle );

Have the test select a known page title, rather than trying to read the text from the option.

It might also be good to assert that the URL added is correct.