New to storybook, playwright integration?

[alexbjorlig]

Hi there.

I'm new to the Storybook ecosystem, and thinking about migrating our stories and tests.

For e2e tests, we use Playwright, and have also started to write playwright component tests.

What is the status of the integration between storybook with playwright component tests - is this possible?

Or maybe to understand this better, how are interaction tests written in storybook - and can we use playwright API to write these tests?

[freed00m]

Hi, what is stopping you to load story and interact with it using playwright?

I just started and the only thing I see so far, that from the storybook UI, you have to change the context to the id="storybook-preview-iframe" or just load the full story url in playwright http://localhost:6006/iframe.html?args=&id=<yourStory>&viewMode=story and just run the test.

[alexbjorlig]

Ok, that might be correct - but then I assume you use playwright e2e and not the playwright component test?

[Marklb]

If you don't mind the story tests being run in a separate process, the test-runner uses Playwright.

I haven't tried it, but I think you should be able to pass a component's composed story to the Playwright mount function, if you use React. stories-in-unit-test You would probably have to call the play function yourself, if that is what you want to run.(@yannbf clarified the play function will not be available, in his response below.) Other frameworks may not be as straight forward, but I am not to familiar with using component tests, since I just use the test runner for my story tests.

[yannbf]

Hey there @alexbjorlig!

Let me add to what @Marklb said and try to explain the state of testing with Storybook. With Storybook, you can define stories for each state of your component, and that is a combination of two things:

1. Rendering
   A combination of decorators, the render function of your story, and its args being applied to it.
2. Play function
   A function that gets executed after the story renders. Useful to get to states that need user interactions, such as filling a form, clicking on a dropdown for its open state, etc. Additionally, the play function can also assert things via expect coming from @storybook/jest, which show a failure in the addon panel if the assertions do not match.

While you could potentially do what @freed00m mentioned, Storybook provides a test-runner which is based on Jest (as a runner) and Playwright (as environment), which essentially turns all of your stories into Playwright tests automatically. It will notify you whether there are failures in the rendering step or the play function step of your stories. The test-runner offer hooks like preRender and postRender, which give you access to the Playwright page instance and its APIs, but they are applied to every story. The transformation happens under the hood so you can't access the transformed test file, neither can you use the Playwright API separately per story. The test-runner is great for people who want to automatically get smoke tests, snapshot tests and accessibility tests to their stories with little to no effort.

---

If you do not want to use the test-runner, but rather want to use Jest/Vitest/Cypress CT/Playwright CT directly, you can use what we call "portable stories", which is a way to use Storybook's composeStories utility to reuse your story setup (the rendering part of it) in your custom test setup. For Playwright CT specifically, given its very constrained nature, you will have to create a separate file for your "composed" stories, like so:

// Button.stories.ts
import { Button } from './Button'
const meta = {
  component: Button
}
export default meta;

export const Primary = {
  args: { label: 'Hello!' }
}

// Button.composed.stories.tsx (or whatever name you prefer)
// Playwright CT does not allow you to create components in the same file it tests, therefore this needs to be in a separate file
import { composeStories } from '@storybook/react'
import * as stories from './IconButton.stories'

export default composeStories(stories)

// Button.test.spec.tsx
import stories from './Button.composed'
import { test, expect } from '@playwright/experimental-ct-react';

describe('<Button />', () => {
  test('renders', async ({ mount }) => {
    // this will render the button alongside its decorators, args, etc.
    const component = await mount(<stories.Primary />);
    await expect(component).toContainText('Hello!');
  })
})

In this scenario, composeStories will return you renderable components that will include the rendering step of what I mentioned above. It will not include the play function, and you won't be able to use it, due to Playwright's limitations. The example I wrote might seem silly and convoluted because it's for a simple button, but if you think about complex scenarios that need theming providers, store providers, routing, etc, all of which are probably already set up as decorators in your Storybook, you will get this behavior "for free", without having to do any of that in the Playwright side, which will save you hundreds of lines of code and make it easier to maintain.

I don't know what you mean by migrating your stories and tests, but I'd say Storybook keeps great value because of its documentation nature, development experience and addon ecosystem, so I wouldn't recommend migrating everything, but I can see value in being able to use Playwright's APIs for testing your components, although the play function could be quite useful for your use cases as well.

[shilman]

Note that this solution of import stories from './Button.composed' requires a fairly recent version of Playwright. They fixed one of Playwright CT's limitations at some point in the past couple months on our request.

[alexbjorlig]

Thanks for such great answers, currently reading through it all and trying to understand the pros and cons 🤓

Will update this thread with my findings, when I have progressed more with the actual implementation.

[yannbf]

@daxit if you were to use Playwright's APIs, that means your Storybook stories would not be portable, for instance you wouldn't be able to have such tests run in the browser when accessing Storybook. You would only be able to have them run as part of Playwright itself. That means your deployed Storybooks would not contain the tests either. Is that a limitation you'd be ok with? The benefit of the play function is that it works in any environment. In your dev browser, in a deployed Storybook, in Jest/Vitest tests with JSDOM, etc. You don't get that with Playwright.

[alexbjorlig]

@yannbf but why is that the case? Is it not possible to integrate playwright with storybook in such a way that playwright is doing the testing part - also in storybook?

[kasperpeulen]

The problem is that the Playwright API runs in Node, and Storybook stories run in the browser.

Have you tried testing with our play function?
https://storybook.js.org/docs/writing-stories/play-function#writing-stories-with-the-play-function

We are thinking about improving the testling library API we now have, and make it more similar to playwright page API.
Would that solve your problems?

[yannbf]

@alexbjorlig Playwright APIs are built in specially to communicate with unsafe Chrome and Webkit developer protocols, which are not available by default in browsers. That's why Playwright launches special browsers as part of its tests (which do enable access to such protocols), and that gives more control and power to it, of course. However that means that you can only execute such APIs if the environment satisfies the requirements.

Storybook and its play function rely on safe browser standards, which is why it's less powerful than Playwright, but also is what makes it portable like I mentioned in my previous comment.

[alexbjorlig]

@yannbf it all makes sense what you write, but then again, as a developer I just want to learn as little as possible when testing :D
I think it would be a good idea to make something as close as possible to the playwright API as possible? That would help :D