testing-library-docs
testing-library-docs copied to clipboard
Add Storybook as Framework
Hey maintainers!
I'd like to contribute Storybook documentation as a Framework .
With the introduction of Storybook Component Format 3, Storybook is doubling down on [Testing Library]. testing-library/dom
is the first-class way to write Storybook tests that interact with rendered components.
Would you accept this documentation if I create a PR that mimics similar framework implementations like TestCafe
, Puppeteer
, and Cypress
?
Thanks for considering this and for providing any feedback that would help me.
Michael
Cool, nice to see it. Is this a framework type of integration (which has its own package), or more of a pattern like the ones for Redux and React Router (under the Examples page, with additional documentation maintained in the main package docs)?
Nice to see you too, @alexkrolick! And thank you for the reply.
We're working out the integration piece right now. My understanding is that it will be published soon as @storybook/testing-library
. The library exposes instrumented versions of @testing-library/dom
and @testing-library/user-event
for the Storybook integration.
Beyond that, the rest would document how Storybook provides a GUI-like experience atop Testing Library.
Most of the other libs are in the @testing-library
org & namespace, which allows the TL contributors to maintain them (propogate breaking changes, etc), but it's probably ok if you want to maintain downstream.
For the docs, we can check out the content in a PR and decide if it should be an Example or a Framework page.
Thank you for the insights, Alex!
It's awesome to here that you would consider maintaining the @testing-library/storybook
under the Testing Library org. I didn't want to jump in with that assumption. But we're happy to discuss an approach that supports the Testing Library community best.
Because it's a relatively new integration, I suspect that there might be a decent amount churn (at least early on). So we'd like to come up with a strategy that doesn't overwhelm your team right off the bat.
Mind if I loop in some of the Chromatic engineers to iron out the details on distribution and maintenance?
With regard to documentation, I'll dive into the other Testing Library Framework docs and feel for the voice and patterns. As we get closer to release, I'll post some proposals here.
Thank you!
What we have done in the past is bring in the packages and then create a sub team for maintaining that framework, so we would just do that for any Chromatic people contributing to it
Thank you for the clarification, that sounds great.
I ran the idea of having having the integration live under the Testing Library org and learned a few things…
Sounds like could work on our end. The bulk integration comes would come from @storybook/instrumenter
— which we maintain across integrations. @testing-library/storybook
would be a thin integration around the latest testing-library APIs.
I took a peak at the proposed library and it appears to do 3 things:
- Warns users when that
within(canvalElement)
should be used instead ofscreen
- Wraps
userEvent
andfireEvent
with an intercepters - Exports the rest of the
@testing-library/dom
The biggest need on our side would be to update the @storybook/instrumenter
version.
With regard to documentation, I'll dive into the other Testing Library Framework docs and feel for the voice and patterns. As we get closer to release, I'll post some proposals here.
Thank you!
Feel free to reach out if you need any help with documentation or any integration @chantastic
thanks @MatanBobi! will do