-
Notifications
You must be signed in to change notification settings - Fork 74
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
[bug] The test runner could not access the Storybook channel #374
Comments
Hey @IanVS thanks for opening this issue! I'll elaborate things a bit so others might have enough context when looking at this issue in the future. The test-runner works by accessing the "iframe" URL of your Storybook, which has just a barebones, isolated version of Storybook with no stories, for instance like here. After that, it accesses Storybook specific APIs to select the story it needs to test. If it can't find Storybook APIs (in this case, the Storybook channel), it will error with that message you got. First, it's important to know whether you're running the test-runner against a local Storybook or a deployed Storybook. It might also help to know whether this happens only in CI or not. Second, this can mean a few things:
If it's none of the above, I really would like to know how to reproduce this so we can fix it! |
Thanks Yann! I've only seen it in CI, but honestly I don't run the test-runner locally because I get very inconsistent failures and timeouts, so I nearly always push to CI and let it run there. Some other notes:
These are the scripts I use to run the tests in CI:
I'll keep my eyes open for any further cases, and see if I can find any similarities. |
I'm also getting this if I run test-runner with I also get:
I tried with both a dev instance of storybook + a built one. this error was with the built one. These stories have nothing special, just smoke-tests. I'm going to try and set up a repo where I can replicate it but might take some time. We use vite for our build, not sure if that helps. |
I also face similar issue as @pedrosousa13: [TEST] FAIL packages/react-ui/src/components/Input/Input.stories.tsx
● Test suite failed to run
[TEST]
page.goto: Timeout 30000ms exceeded.
[TEST] Call log:
- navigating to "http://localhost:7006/iframe.html", waiting until "load"
[TEST]
at defaultPrepare (node_modules/.pnpm/@[email protected]_@[email protected]_@[email protected][email protected]_27kwgapvhdmhdh2inwdzlb3z3e/node_modules/@storybook/test-runner/dist/index.js:13241:14)
at setupPage (node_modules/.pnpm/@[email protected]_@[email protected]_@[email protected][email protected]_27kwgapvhdmhdh2inwdzlb3z3e/node_modules/@storybook/test-runner/dist/index.js:13273:11)
at CustomEnvironment.setup (node_modules/.pnpm/@[email protected]_@[email protected]_@[email protected][email protected]_27kwgapvhdmhdh2inwdzlb3z3e/node_modules/@storybook/test-runner/playwright/custom-environment.js:8:5) I am also using I suspect it is related to In my case, I am running concurrently -k -s first -n \"SB,TEST\" -c \"magenta,blue\" \"storybook dev -p 7006 --ci\" \"wait-on http://localhost:7006 && test-storybook --url http://localhost:7006 -u The snapshot test occurs in the // simplified for illustrative purpose
(
...,
async postVisit(page, context) {
await ctx.waitForPageReady(page)
const image = await page.screenshot()
expect(image).toMatchImageSnapshot(...)
await switchTheme(page, 'dark')
const image = await page.screenshot()
expect(image).toMatchImageSnapshot(...)
} |
could be related to #444 |
Describe the bug
I'm not sure what can be done to fix this, but I've gotten an error in a single test, which was resolved upon a re-run of the job:
To Reproduce
No idea, it's not something I've seen often, and appears to be intermittent. The story is nothing special: no args, no play function, just static content.
Expected behavior
I wouldn't expect flakey behavior from the test runner.
Screenshots
If applicable, add screenshots to help explain your problem.
System
Additional context
This isn't probably immediately actionable, but I wanted to open an issue to see if others are hitting this as well, in which case we might want to look into why it could happen.
The text was updated successfully, but these errors were encountered: