Tabs keyboard arrows accessibility test on @testing-library/*

[kimdgutierrez]

Hello, Radix! First of all great library and great work what you have done on this project!

We are currently trying-out the @radix-ui/react-tabs and we would like to test the basic accessibility navigation as sort of fail-safe. However, it seems that tabs is not responding to keyboard arrows, but it is responding on tabs and locking on Tab list (first-button), just unable to switch the focus between buttons.

I've been playing on this sandbox to recreate the problem, but this one is producing a bit different behaviour, on first TAB it locks on the role="tablist" instead of the first role="tab", this makes it tricky to give you the best picture of the first problem were having. But yeah, there is no really special requirement we just want to test a11y described here.

Reading on existing issues and looking at the tests you have, it could simply be that the library is not there yet in terms of rigour testing? That being said we wonder about our (radix) roadmaps especially on testing and libraries to support as we see that we are leaning more towards cypress and that @testing-library/* doesn't play well yet on some packages, can you please enlighten us on this?

Thank you and good job on this package!

[benoitgrelard]

Hi @kimdgutierrez,

You shouldn't really have to re-test the library, that's a bit like re-testing that React itself works.
That being said, the issues you're having are most likely due to the fact that Jest isn't the best way to test components like these as you rightly pointed out (mentioning cypress).

This is likely some timing issues in your tests or some discrepancies around focus management in jsdom vs. a real browser.
I would definitely encourage you to use Cypress rather than Jest to test UIs as it is much more real/accurate and reliable.
But again, I don't think you should waste time re-testing the libraries you're using either, you should test your own UIs/app logic instead.

Hope that helps!

[JodiWarren]

Hi @benoitgrelard, sorry for the confusion. I'll try to ask with a bit more clarity.

We're really enjoying Radix UI. The API is great, and our manual tests are so far showing that each component is behaving exactly to the ARIA patterns. The docs are fab too.

The blocker is that we have an internal requirement to validate all accessible behaviour with automated tests. As you suggest, we shouldn't re-test behaviour that you're already testing. Can you describe how Radix tests the Tabs components? If there are automated tests, I would appreciate a link to them. That would be information that I could pass on, and allow us to adopt Radix more thoroughly.

[benoitgrelard]

Ah I see, we currently don't have automated tests for the entirety of the library so it looks like tabs isn't covered.
We have a lot of automated coverage via Chromatic UI through storybook.
Our goal is go keep adding more behaviour coverage via Cypress as per the existing ones already.
Hope that helps.

Cypress would definitely be my recommendation to you to tests these UI/behaviours.

[JodiWarren]

@benoitgrelard Fab, thank you for the answer! Really useful. Can we see your Chromatic instance? It's just for my own curiosity.

[benoitgrelard]

I think you should be able to view this publicly: https://www.chromatic.com/library?appId=601857eb614bae0021c9b9dd&buildNumber=1901

[JodiWarren]

That works perfectly. Thank you for your responses!