Discussion - Is storybook interaction testing a better approach

[srleecode]

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:

• https://storybook.js.org/blog/interactive-stories-beta/
• https://itnext.io/cypress-component-testing-vs-storybook-interaction-testing-fe1f0270d30a
• https://testing-library.com/

The main advantages I can see for the current approach are:

• the same component test harnesses can be used in the UI tests and the E2E tests. For the above approach, it seems like you would need similar, but different code. That is, cypress-testing-library for the e2e and angular-testing-library for the UI tests.
• there are existing component test harnesses that can be used for some of the material/cdk components
• It renders in cypress which makes it easier to debug and to see what is happening in the test.

The main disadvantages I can see are:

• speed
• needing to also setup another thing (cypress files and builder task) besides storybook
• component test harnesses are still complicated to use and for example besides efforts like your library don't support cypress. This means they probably have a smaller level of development effort than the testing library would.

[edbzn]

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.

The main disadvantages I can see are: speed

Well, would be interesting to measure Storybook interaction testing speed compared to the Cypress component testing.

needing to also setup another thing (cypress files and builder task) besides storybook

That's why we provide generators for setting it up quickly, I don't think it's a disadvantage.

component test harnesses are still complicated to use

Cannot disagree, it's the main issue I think.

besides efforts like your library don't support cypress

What do you mean?

[srleecode]

besides efforts like your library don't support cypress

What do you mean?

Let's skip this point as it doesn't matter.

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.

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.

[edbzn]

Let's skip this point as it doesn't matter.

Ok, if you have criticizes I would be happy to hear them!

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.

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?

[srleecode]

I consider Storybook as a playground to isolate component development outside an application context

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.

I don't see the benefits of developing them into Storybook. Do you have other views on that?

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
This is an example with interactions: https://next--storybookjs.netlify.app/official-storybook/?path=/story/addons-interactions-accountform--verification-success