Tabs: Fix flaky unit tests

[chad1008]

What?

Fix two flaky unit tests that were first mentioned in #55287 (comment)

Why?

Because no one likes a flaky test.

How?

Two tests had issues, and were solved by ensuring the component had time to fully update before proceeding.

Tabs › Uncontrolled mode › Disabled tab › should disable the tab when disabled is true

While debugging, I noticed that tabindex=-1 on inactive tests wasn't always being applied in time in the testing environment. This allowed the next tab in line to receive focus, triggering a failure. The new assertion waits for this property to be present before proceeding, ensuring an accurate test. I'd prefer we didn't need an assertion for this type of under-the-hood detail, but I'll take it over flakiness.

Tabs › Tab Activation › should not focus the next tab when the Tab key is pressed

This test relies on pressing the [Tab] key, followed by the [ArrowLeft] key, and then checking that the proper tab has focus. The focus check was happening too quickly sometimes, and new focus hadn't been applied yet. The new assertion waits for and checks the focused element after the [Tab] key, ensuring the new focus is applied before [LeftArrow] is pressed.

Between different testing runs I ran the full unit test suite about 100 times without any failures.

Testing Instructions

note: I didn't encounter the flakiness when running the tests individually, though I maybe just didn't try enough. I just ran the full suite instead and recommend testing this PR the same way.

• After the test finishes, re-run with Enter/Return.
• Repeat approximately 372 times. Or, you know... just a bunch.
• Confirm that anti-flaky status has been achieved.

[ciampo]

cc'ing @diegohaz in case he has anything to add —we have already experienced flakiness when testing ariakit components with @testing-library/user-event a few other times, and although I haven't testing this in person, this fix looks like a good approach.

I also wanted to flag that, during my work on DropdownMenu, I ended up using the @ariakit/test to simulate user interactions instead.

[chad1008]

@ciampo did you think we should go ahead and merge this one now, and if @diegohaz has any recommendations later, we can address them in a followup as needed?

[ciampo]

Yes, this sounds like a good approach 🚢

(also, interesting to see that the CHANGELOG check is not running?)

[tyxla]

LGTM 👍

FWIW, this has been what I've been suggesting as a solution for when we want to ensure the Ariakit store has finished initializing. Thanks for adding the comments to clarify what we're doing.

[chad1008]

(also, interesting to see that the CHANGELOG check is not running?)

😆 That made me pause too, but then I remembered that we specifically excluded PRs that only change specific files like tests, since we don't usually add entries for those.