feat: Reusable tests #7011
feat: Reusable tests #7011
Conversation
There was a problem hiding this comment.
I like the idea of having standard tests built at the aria level that then the actual library implementation of the aria pattern can then reuse, definitely makes it more efficient. My only concern would be the more complicated nature of the setup haha, certainly more strict with the structuring than writing the test as you'd like for a given component. I think it will be beneficial in the long run though but will have to give it a shot first before further judgement
| it('has default behavior (button renders, menu is closed)', function () { | ||
| let tree = renderers.standard(); |
There was a problem hiding this comment.
Interesting, I like the reusability of these tests, essentially establishes a standard suite that theoretically ANY implementation of the aria menu pattern could directly use. I assume you brain stormed these first and then pulled out/reused duplicates from the existing suites?
There was a problem hiding this comment.
I did it a little more organically than that, I pulled out from the current React Spectrum MenuTrigger almost 1:1, then started grouping based on how different the render requirements were.
I set out to have the tests be agnostic of dynamic case, or static case, or uncontrolled, or controlled, but that was as much as I had originally planned ahead
| }); | ||
| }); | ||
|
|
||
| // better to accept items from the test? or just have the test have a requirement that you render a certain-ish structure? |
There was a problem hiding this comment.
I'm personally leaning towards the test having a requirement that you render a certain structure of menu, would make it easier to have others reuse the tests for their own implementation. If we aren't interested in that (it would be a lot of work to take on), then maybe we could accept items/button label/any other standardization from the test perhaps
There was a problem hiding this comment.
Yeah, I'd like to decouple more from the react testing library render or React in general, but right now it's still baked in pretty hard thanks to act most specifically.
Goal for another time, but hopefully this helps set us up for it eventually.
|
I've also updated the utils PR with the remainder of the comments, apologies about the conflicts but hopefully they aren't too bad |
no worries, it wasn't that bad |
snowystinger
force-pushed
the
reusable-tests
branch
from
c509656
to
73a868c
Compare
devongovett
force-pushed
the
main
branch
2 times, most recently
from
a79adcf
to
3013156
Compare
…more interaction types
snowystinger
force-pushed
the
reusable-tests
branch
from
f5b196b
to
a52077c
Compare
|
I'll see about rebasing my test util docs PR against this one soon, but I think the changes/conflicts will be pretty superficial |
# Conflicts: # packages/@react-spectrum/s2/package.json # yarn.lock
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Closes
General idea here is that a test suite is built that tries to be as agnostic of the content as possible. Instead, based on a set of conditions which need to be met per-renderer, it will test aria patterns.
If we want to test controlled states, we just create a renderer which renders a controlled implementation of the component. This allows us to test things like the onChange/value props indirectly. This leaves as much of the API for each component as possible up to the implementation.
If a renderer is not provided, then a set of the tests are skipped. This is useful because you may not want or need to run the absolute full suite on every implementation. You may also not have implemented a particular aria feature yet, but it's good to have tests on everything else. You can turn on those tests when you implement the feature easily enough.
Still working on API for it.
Spectrum v3 and s2 tests would be restricted to their own suites using Daniel's work to simplify.
✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project: