Storybook can do.... WHAT???
ฝัง
- เผยแพร่เมื่อ 30 ก.ย. 2024
- Bet you didn't know that Storybook can do THIS! Zack walks you through the benefits of Storybook, and how you can instantly get setup to be productive with Storybook using the integrated tools from the @nx/storybook plugin, including how you can get new interaction tests up and ready to go!!
== Links ==
nx.dev/docs
blog.nrwl.io/s...
== Socials ==
Nx: / nxdevtools
Zack: / zackderose | @Supaship6000
Can these tests be run in github actions?
Yup! the same generator will create a target to run the tests as a command that will pass or fail.
@@Supaship6000 can you point to an example, because right now i have the problem, that the test-storybook target does not spawn a server. my use case would be that affected libraries spawn their storybook server and test them
In a real project where we have hundreds of components and modules, would you suggest using storybook interactions as a base for TDD? How fast would the feedback loop be? What would the pipeline look like?
IMHO storybook interactions are only suitable to e.g. force open a modal in a story.. Not for testing
Hey there, SB maintainer here. You get instant feedback for TDD inside of Storybook because the tests run in the browser. As you develop, you can see the results of your tests right in front of you. There's no extra step or other stuff to run. The API under the hood is Testing Library.
Pipeline is to use SBs Test Runner in CI. You could also use Chromatic to run the tests in parallel across browsers. Totally up to you.
@@dominicnguyen5465 Thanks for your reply. I'd like to mention that, despite some annoyances with set-up and additional maintenance work, Storybook is a great tool and is a must have in all my projects.
A year and a half ago I started a new full-time project, which continues to this day, in which we used storybook interactions when they were still in beta. I have some experience with this tool.
For a few months now, I have been practising TDD as it is described by Kent Beck, i.e. for example: the entire development process of a front-end module is based on red, green, refactor. One change can change a lot of observable behaviour. For this reason, I need to have an immediate view of the results of all tests after each change. For this reason, I need to check the terminal rather than the browser and each story/test individually. Integration of the tests with the IDE is also crucial. You could create a video showing such a workflow, in a real world app, if you think DX is good at this.
I know from experience that one of the most important parameters (if not the most important) is the time in which we have a response from the tests. If the project is very large (and has more than, say, 2000 tests), every extra millisecond on each test significantly affects DX, development speed and confidence in what we are doing.
While I have not measured, it seems to me that tests through Storybook interactions are famously slower than tests done directly in Jest.
Another problem I see is this dependency: one test is one story. A simple TODO module may have about 100 tests, in which case I will have 100 stories? The Storybook stops being a clear inventory of the components used in the project and becomes "littered with story tests"
Another problem I see is that in order to be able to run tests, I need to have Storybook running in the background (maybe I'm wrong?). The test environment becomes even more complicated and dependent on additional tools. The response time as to whether tests pass is increased.
It is good if all unit and integration tests are in one place and run with one command. i.e. we should write tests, either directly in Jest (in .spec.ts files ) or in storybook interactions. Otherwise TDD is severely hampered.
What won me over to Storybook Interactions was the ability to preview the individual steps in a given test in the browser. Pausing and scrolling 😍 great stuff.
Interactions are ideal in combination with chromatic. I.e. we want to do a visual regression of the dropdown with dropdown visible.
If I could make a suggestion, it would be ideal to integrate the Jest or Vitest files with the storybook, so that you can see what tests we have written for the component and be able to play them in the browser. However, the tests should not be directly coupled to the Storybook via Interactions
That pretty cool actually. Need to try immediately.
Very important statement you start out with. Another important thing is that with “interaction testing on Storybook”, you probably don’t have to test it during E2E.
I was wondering how to put all stories together?
thanks for the video! this looks really useful in some scenarios