Component testing in Storybook with play functions

Component testing in Storybook let’s you describe stories with user interactions!.
In this video you’ll learn how to write component tests with play functions - Storybook’s way of describing stories thru user events and interactions.
With play functions you can describe UI - not only as a function of props and state - but as the result of clicks and key-presses.
Learn from chantastic to use the Interactions Addon, write play functions with testing-library, and assert states with Jest…
▬ Follow us! ▬▬▬▬▬▬▬▬▬▬
Discord: / discord
Twitter: / storybookjs
Instagram: / storybookjs
GitHub: github.com/sto...
Follow ‪@chantastic‬ on:
twitter: / chantastic
youtube: ‪@chantastic‬
▬ Learn more ▬▬▬▬▬▬▬▬▬▬
Storybook Interactions Addon: storybook.js.o...
Storybook Test Runner Addon: storybook.js.o...
Writing interaction tests documentation: storybook.js.o...
Storybook 6.5 Announcement: storybook.js.o...
Interaction testing with Storybook post: storybook.js.o...
Testing component interactions with Storybook: storybook.js.o...
Automate accessibility tests with Storybook: storybook.js.o...
Thinking in React (classes): reactjs.org/do...
Thinking in React (hooks): beta.reactjs.o...
Storybook at learnstorybook...
Storybook addons at storybook.js.o...
Component driven UI development at www.componentd...
▬ Free Storybook hosting ▬▬▬▬▬▬▬▬▬▬
Chromatic is made by Storybook maintainers and sets up in just 2 minutes.
Claim free Storybook hosting at www.chromatic....!

[@chromaticui]

Correction from an engineer on the team. The assertion should have an extra set of parenthesis around the promise, before .length is called: expect((await canvas.getAllByRole('row')).length).toBe(4)

[@joshdegraw3086]

I opened the comments to complain about that lol

[@jennifer7chan]

🤣

[@jeffmccloud905]

Actually, they're wrong, sorry... "await" isn't even necessary here (nor the extra parentheses). getAllByRole doesn't return a Promise. In the video, notice the little dotted underline under the "a" in await? VSCode shows this when the await is unnecessary (Hover over it and it will say "await has no effect on the type of this expression"). It's not necessary on your getLabelByText or click calls either.

[@megaroeny]

Y'all are killing it with these new videos. I love that you are even showing what code to write, which is fantastic for beginners or a broader audience in general! Keep it up!

[@chantastic]

thanks for the encouragement Reony! this has been a fun new challenge for us. and we're really grateful for your feedback. let us know if there's anything you'd like for us to cover. we'll get it in the queue!

[@andyvennells2034]

Love your videos. No fluff, engaging and straigh to the point

[@chantastic]

Thanks so much Andy! I'm so grateful for this encouragement!

[@Thisis_Sathish]

Great content a content-oriented video. Cool stuff with engaging way of teaching. you are making my day something insightful.

[@chromaticui]

Wow! Thanks you. We're so glad to have made your day. Thank you for making mine (chan) too!

[@thohangst]

I admire the zeal. Not everyone can muster it. But it does make the work a bit more enjoyable, much apreesh.

[@chromaticui]

thank you! this is a wonderful complement 💝💝

[@SleppySnek]

I've been playing around with this and I like it so far. I think there's a lot of potential with this. One of the things I was trying to do, was to make some chromatic snapshots consistent by mocking some javascript animations by using jest fake timers, but it looks like that is not possible yet. Could be something to consider adding! Another thing that might be interesting, is to combine this with chromatic snapshots. E.g. take a snapshot before and after doing an action instead of having to make two stories for it.

[@chantastic]

Glad that you're liking it! Have you come across this article on animations in Chromatic? www.chromatic.com/docs/animations#javascript-animations I think that it may be just what you're looking for. Many JS libraries have a way to globally opt out of animations. You can set your Chromatic snapshots to set this option, only when in the Chromatic environment (uses the isChromatic check).

[@SleppySnek]

@@chantastic Thank you for the suggestion! (apparently youtube don't want to inform my anymore of replies to my messages, but thankfully I saw it) I did know of that method, but I have since discovered that animations are not the only thing that give me problems with those stories. Now those stories have "pauseAnimationAtEnd: true" and "delay: 2000", but for some reason it is still inconsistent. I'm using the Material UI tab components and the tab indicator just doesn't want to stay in one place no matter what I do, with or without animations. But the component itself works perfectly in storybook or when testing manually. In chromatic it's just always a few pixels of difference for some reason. In any case, I don't want to bother you with this in the comments here, so I'll have to investigate further!

[@chantastic]

@@SleppySnek interesting. it sounds like you're trying the right things. are you part of the storybook discord? there's a lot of great experience in there. there may be more experience with your specific library. discord.com/invite/storybook

[@SleppySnek]

@@chantastic Oh, good to know that exists. But unfortunately the company security policies are very strict and there's no way I'm ever getting access to discord. Thanks a lot for trying to help though! I'll probably try out some more things when I get the chance, or if all else fails, there's still the help chat I noticed on the website.

[@uwemneku1917]

This is amazing

[@chantastic]

thank you so much! if you have anything you'd like to see a video on, let us know!

[@jennifer7chan]

Haven't taken advantage of these play functions yet. dayumm!

[@chantastic]

they're SOOOO good

[@corneasp9418]

How can I set different loaders for play functions? Or better yet, update args as I go through a scenario in a play function? storybook 7 & csf3

[@aarsnowangel1391]

Hey, thanks for this great video. I am using Storybook with StencilJs - any chance you know when interactions will work with the shadowDom?

[@chantastic]

Thank you for the encouragement Nicole! I asked the team and it looks like our shadowDom support is dependent on testing-library's support. They Storybook team shared a fork of testing-library that works with shadowDom. But my understanding is that it's still experimental. Here's a link to the open discussion: github.com/storybookjs/testing-library/issues/24#issuecomment-1165222880

[@alexmachin1785]

I'll eventually get to writing unit tests with Storybook. This looks really cool though 🙌 In the video you use Storybook jest package, I take it you can use vites testing framework if you use Vite?

[@chantastic]

unfortunately, there is not a vitest integration yet. i've put the feelers out tho. really hope that it comes soon, now that we have vite support

[@ManuelSalvatori]

Very nice I didn't know about this new feature, I am already on 6.5.x but I don't have the addon, most likely because I kept upgrading my first installation, which was probably around 4.x? I have a question I use storyshot and I was wondering if the play function has some level of interoperability with storyshot, for example if storyshot was able to understand when one interaction was completed to take a snapshot before moving to the next interaction. Thanks

[@chantastic]

Hi Manuel! This video should cover the setup: kzbin.info/www/bejne/rXbEZ4puqrp6iaM This is the article where they were introduced, with install instructions. Hope that helps! storybook.js.org/blog/interaction-testing-with-storybook/

[@kristaabraham8680]

Hey, great video! Is it possible to reset components to their original state after the play functions run? Just thinking that since the interaction tests run when the component is loaded, they could end up focused, expanded, or even dismissed - which could be problematic if also using storybook for component documentation.

[@chantastic]

Great question. To answer the direct question: yes. The interaction testing addon has a feature flag that exposes a step debugger for interactions. Here's the blog post shares that information. Just know that it's not completely reliable yet (hence the flag) storybook.js.org/blog/interaction-testing-with-storybook/#:~:text=Optionally%2C%20enable%20playback%20controls%20in%20the%20interactions%20addon For my own Storybooks, I usually start with a `Default` story that tests the component free of args and interactions. As a pattern, that's the best place for anyone to tinker with any of my components. From there I'll add stories with various combinations of args and interactions to validate and test (with Chromatic) my visual assumptions. These are generally less useful for documentation. It would be interesting to see Storybook adopt a way to showcase these differences.

[@manuelasousa9037]

Hey, this seems very powerful however i have a question. Which types of bugs this finds and when? Ex. After class is changed etc

[@alex_mir888]

Hey, great video. I have a question about your example, because you have one component with action, but what do I have to do if my component opens different component for example button opens card? How to simulate this action in storybook?

[@chantastic]

That's a great question! It'll depend a lot on what you're trying to test. For example, I've used this to test alerts. It that case, I assert that the button is there, click the button, then assert that the correct alert showed. If the goal of the test is simply to assert that the functionality works in revealing a provided component, I generally some form of stand-in component. Something that's not a real component in my system but clearly just a test. This way my assertions are made on locally defined values and not dependent on an imported component (with source elsewhere in the codebase). If both the container and contents are part of the same component, I'd feel more comfortable asserting the revealed content as part of the tests.

[@jeremytenjo]

Amazing! Can we run tests in the terminal ?

[@chantastic]

thanks Jeremy! we're running the tests from the terminal currently. are you asking if we can run the tests in i simulated DOM, like JSDom? i do believe that is *possible* but not something we have guidance on. philosophically, we believe that UI tests should be run in browsers.

[@witchmorrow]

Hi there, please could you tell me - is Storybook testing envisaged as a replacement for React testing (eg React Testing Library), or do they have some differences? Thanks!

[@chromaticui]

Thanks for asking, Scarlet! At the moment our integration is focused on testing-library/react-testing-library. I'm not familiar with testing envisaged. Could you send us a link?

[@winkerVsbecks]

Storybook testing uses Testing Library (DOM) under the hood. It's meant to replace jest tests that are run using JSDOM. The syntax for Storybook testing is the same as Jest + TL. The only difference is that the tests run in an actual browser.

[@witchmorrow]

@@winkerVsbecks ahh okay thanks that makes sense

[@NavyCuda]

I'm not very good... but I've written myself a nice little custom binder to simplify putting args on different stories.

[@chantastic]

Nice! This is something that I really like about CSF3 - when used with the object syntax, you get an automatically bound args. It's great storybook.js.org/blog/storybook-csf3-is-here/

[@joseluisdevegaandres9299]

Can we use interactions with web components?

[@chromaticui]

unfortunately, it looks like not at the moment. at least, it's not setup up in the repro for lit2

[@bonarhyme]

Please what is the right way to test aws amplify and graphql?

[@chromaticui]

with Storybook?

[@bonarhyme]

Yes.

[@xennialmusic]

Where are the full docs on the canvasElement API? All of these getByRole and getByPlaceholderText are foreign, and tbh a bit counter-intuitive to most other types of e2e selection tools. I'm used to Puppeteer with page.find(cssQuerySelector) and need to reference all of the possible canvas methods.

[@chromaticui]

They are Testing Library APIs. They may feel counter intuitive at first but are designed to mimic how a user navigates the site - which is aligned with their goal of prioritizing accessibility. testing-library.com Playwright recently adopted these methods into their e2e APIs. github.com/microsoft/playwright/releases/tag/v1.27.0

[@VenugopalKathavate]

Can we use play() function to replace component unit tests?

[@chantastic]

i think yes. my personal belief is that visual tests are a much better way to test UI components. because they use the actual browser that users will use and evaluate the entire UI (not just a serialized version of it). we have a few additional resources that you may find interesting: - Tame the UI Multiverse (a talk I gave last year) kzbin.info/www/bejne/fqHbZJ6FqbWirM0 - Why most design systems implode (a summary of conversations we had with Brad Frost about modern UI development) storybook.js.org/blog/why-most-design-systems-implode/

[@chun-lunlin7397]

why we want to write this unit test-ish interactions instead of writing a actual unit test? feels like we are using the storybook like a test platform not a simple component demonstrate platform. are we using the storybook the wrong way?

[@chromaticui]

i may not understand the question. what would be required to qualify it as an “actual unit test”? isn’t a test that runs UI in a browser more actualities than one that runs in JSDom? chan

[@kimberlycaritas]

Has anyone ever had (& solved) issues with interacting with content in the canvasElement when your component is in the shadowDOM? I haven't been able to get play tests to work on our company's application because the canvasElement can't see/identify anything inside the shadowDOM.

[@chantastic]

Hi Nicole! I asked the team and it looks like our shadowDom support is dependent on testing-library's support. The Storybook team shared a fork of testing-library that works with shadowDom. But my understanding is that it's still experimental. Here's a link to the open discussion: github.com/storybookjs/testing-library/issues/24#issuecomment-1165222880

[@vesvezz]

Hello, I've got quite a few tests written already using Vitest, as far as I know Vitest's expect func is compatible with jest. How can I bring those tests to storybook? Thanks!

[@chromaticui]

thanks for the video suggestion. vitest is something that we're investigating but don't have official guidance on yet. if you find helpful resources, let us know and we'd love to produce a guide!

[@vesvezz]

@@chromaticui Of course, I'm already tooling around, trying to find some clues, If I'm able to figure it out, sure thing I'll share it! Many thanks for the reply 😃

[@st.kamnakis]

How would I run all tests (without navigating to each story) to check that a change doesn't break something?

[@chantastic]

That's a great question! I'm hoping to tackle more automated test topics in the near future. The test-runner (the low-level addon thot powers Interaction Testing) can be used to run tests in parallel and report errors across tests. You can read more about it on the 6.4 announcement post: storybook.js.org/blog/interaction-testing-with-storybook/

[@dominicnguyen5465]

Test Runner should do it storybook.js.org/docs/react/writing-tests/test-runner

[@st.kamnakis]

@@chantastic That's great! Thank you!

[@chantastic]

@@st.kamnakis any time! I hope it helps

[@TwoLeggedTriceratops]

Is this testing framework-agnostic?

[@chantastic]

yup! this uses the framework-agnostic version of testing-library