-
-
Notifications
You must be signed in to change notification settings - Fork 15
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
Discussion - Is storybook interaction testing a better approach #130
Comments
Hi @srleecode, I was not aware of this interactive storybook testing feature, thanks for sharing it. Let me share my first impression, the included solution looks great for testing dumb components, the testing library gives a clean approach for writing maintainable tests, and it definitely makes Storybook more powerful. Storybook becomes the swiss army knife for component development. On the other hand, I think it's not best suited for testing smart components, they are rarely developed within Storybook and I think the Cypress Component Testing particularly shines for this use case. Regarding, the Component Harnesses, I agree the API is not user-friendly, and I think it's a problem for their adoption outside Angular Material, but we should keep in mind it does not provide the exact same functionalities as the Testing Library. Component Harnesses offer more abstraction to interact with the view, we can leverage typed methods rather than querying the DOM directly. This says we can use the Testing Library to develop more maintainable Component Harnesses for instance.
Well, would be interesting to measure Storybook interaction testing speed compared to the Cypress component testing.
That's why we provide generators for setting it up quickly, I don't think it's a disadvantage.
Cannot disagree, it's the main issue I think.
What do you mean? |
Let's skip this point as it doesn't matter.
Can you please explain this a bit more. I don't know why storybook would not be suited for developing and testing smart components. I have been developing smart components in storybook. The main difference from dumb components is that you need to mock out the endpoints. |
Ok, if you have criticizes I would be happy to hear them!
I consider Storybook as a playground to isolate component development outside an application context, the main advantage is that you think your component in a generic way. However, smart components are bound to an application context, I don't see the benefits of developing them into Storybook. Do you have other views on that? |
Storybook is useful for documentation of reusable components which I believe is the case you are thinking about. Since they should be reusable components they are likely to not have an application context as they need to be generic.
Storybook isolates components, but those components don't need to be the low level components like buttons and text fields that are shared and reusable. They can be higher level components that use multiple components and implement a feature for an application. For these components, documentation is probably less important as they are not components that are likely to be reused. However, in my opinion this doesn't matter too much as the main value from storybook comes from its ability to give fast and useful feedback. This feedback can come from things like automated testing in the browser, visual testing or manual verification like a designer reviewing what a developer has done. In all these cases, being able to see directly an isolated component in a particular state saves a lot of time versus doing something like running the application. As an example, If you were working on a component in the third step in a wizard with the application approach each change would mean that you would need to go through the previous steps in the wizard again. Doing that a 20 times can get annoying and can take up a lot of time. FYI |
What do you think about storybook interaction testing and would it be a better approach than the cypress component test runner and component test harnesses. See the below for more information:
The main advantages I can see for the current approach are:
The main disadvantages I can see are:
The text was updated successfully, but these errors were encountered: