-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add tests #58
Comments
I'm going to start working on something for this today. Here's what I'm thinking so far: Setup StorybookUsing Storybook, we can easily create reliable, testable pages with configuration options for each component. Setup BackstopJSUsing Backstop, we can create regression tests for each component. Testing obviously provides a lot of value, but the biggest win here is that we can disallow PRs from being merged if they cause regressions. Setup Storybook DeployerStorybook Deployer handles deploying storybooks as static sites. this would allow us to actually host our Storybook on Github Pages for users to fiddle with. 😁 |
I'm implementing BackportJS, I'm afraid I'll have 100s of scenarios to test all storybook's components, I was thinking if we could render all stories and their variants on one page, and test just that one page, so when any new story or variant is added, its automatically tested by BackportJS. I see there was some effort put to create functionality to load all stories and their variants on one page. Is this a good/right way to solve implement BackportJS with Storybook? |
First, let me verify that I'm understanding your concern. I believe that you're referring to this section of the Backstop config, and your concern is that adding scenarios for every variant of every component to that one file is gonna suck. I would agree with that, but I don't think that putting all of the components with their variants on one page is the right solution. It'll make it much more difficult to determine where exactly the issues are occurring. Alternatively, we could switch to Storyshots. Basically, it's a Storybook addon that will automatically add snapshot testing in for each of our stories. We may need to write additional tests to make sure it tests each variation of each component, but it looks like it'd be a pretty great starting point. |
This article indicates that we can pass a We could potentially go even further, creating our own version of Storyshots that leverages Backstop, generating all of our URLs to test from our stories and knobs. That's probably a bit overkill at this point, but the option is there. |
I don't know if we will have to create our own version of Storyshots, that would be a fun challenge to work on. @trezy nice work on that research 🙌 |
Hey @evexoio, what's the status on the Backstop work? |
@trezy hey, I've done the tests where the scenarios are just radios(e.g. balloons, buttons) in storybook. Now I'm figuring out a way to generate all the scenarios when using radios, select and boolean scenario types(e.g. containers, icons). I'm getting there 🙃 |
No worries, @evexoio, thanks for the update! I'm excited to get the tests done so we can prevent regressions via CI. 😉 |
One thing that might be worth looking into is using a service like percy to run the tests. That way the tests themselves don't need to live in the repository, and all of the issues with rendering differently on different machines don't have to be dealt with. I recently integrated visual regression testing for the ui component library for which I'm responsible at work, and a combination of jest, jest-puppeteer, puppeteer and percy worked quite nicely. If you're curious, I wrote a blog post about the experience here. I know that percy does have some integrations with storybook (we didn't use it though), and they do have a free tier of 5000 snapshots per month. We combined multiple states of the components into one snapshot per component to save on snapshot $$$. It should be doable to use a free plan with this repo. |
Testing visual frameworks is haaaaaard, but we can do eet! I prefer BackstopJS, but any visual regression testing tool would work. This would go very well with #38, as we’ll need something that renders the pieces of the framework to test. Adding docs would also go hand-in-hand with this as we could then just run the tests against the docs.
The text was updated successfully, but these errors were encountered: