[microsoft/playwright]剧作家 CT / 故事书整合

@microsoft-github-policy-service 同意公司=“Chromatic”

@sand4rt ^^

:wave: 迈克尔，很棒的演示！这正是我想象中与 Storybook 集成的样子。

我可以看到 Storybook 用户如何喜欢这种集成 - 他们已经有了适当的故事，Storybook 正在处理重量级捆绑，创建测试很简单。

对 React / Vue / Svelte 的 Vanilla 支持将涵盖非故事书需求 - 我们的运行时和捆绑的成本本质上是 0，我们在关注点分离方面没有固执己见，我们在表达方面更接近 Jest 风格并组合组件。

就这个 PR 而言，我不认为test-components-storybook-js.md属于 Playwright 存储库 - 当您test从导入时playwright-ct-storybook，您实际上是在记录一个单独的产品。我实际上很喜欢它在https://github.com/storybookjs/playwright-ct上的导入和记录方式。

嗨帕维尔，感谢您的反馈。 ？你是对的，这test-components-storybook-js.md可能是不必要的。我已将其从 PR 中删除，但保留了描述/链接，以便 Playwright 用户可以了解该项目。你怎么认为？

@shilman：我们首先向现有故事书用户荣誉提及基于故事书的方法怎么样？我们可以指向一个包并给出一个片段，其中包含从测试中导入的故事文件。然后我们将通过耳朵来种植它，但现在我不想在技术问题上阻止这个 PR。

@pavelfeldman 很高兴从这里跟随您的领导。将继续在线程中进行技术交流，因为我认为这是很重要的一点，但我对文档中的内容持灵活态度。

嘿@shilman？不错的演示！另外，嗨@kasperpeulen，你现在在 Storybook 上工作很酷吗？

我还在之前使用 Storybook 的公司开发过涉及 Storybook、React 和 Playwright 的原型。它直接使用 来安装组件@playwright/experimental-ct-react。想知道您是否考虑过这种方法？我在这里看到的缺点是它只兼容 Vite，并且还没有对其他一些框架的官方支持。目前还没有或部分支持元框架，例如 Next 和 SvelteKit。尽管如此，Playwright 组件测试仍然相对较新。

我确实认为两者@storybook/playwright-ct都@playwright/experimental-ct-{framework}面临着相同的障碍并且有相同的解决方法；具有无法被剧作家序列化的道具的组件必须在故事中或仅在包装器/组件文件中定义。虽然由于故事文件中现有的组件定义，这在 Storybook 的情况下更容易被接受，但障碍仍然存在。

Storybook、Playwright 和其他组件测试解决方案似乎有某些相似之处。虽然我还没有进行深入的探索，但似乎共享包有潜力，特别是在涉及 SSR 和渲染组件与元框架特定功能隔离的场景中。

@shilman 我也很好奇您对立即将这些信息包含在文档中是否为时过早的想法？该库还很新，下载量还不是很多。

@sand4rt 感谢您的善意留言。事实上，CT 世界中的解决方法只是 Storybook 中的标准程序。我们绝对正在研究在其他工具中重用故事的其他方法。您可以在此处查看“便携式故事”的第一个原型，我们将在未来几个月内发布跨所有渲染器的更通用的版本。

我们也可以通过这种方式与 CT 集成。此 PR 背后的基本原理是探索一种符合人体工程学的方法来重用故事和 Storybook 的渲染，这比 CT 领先了许多步骤。与可移植故事集成后，用户将失去诸如特定于框架的构建功能、Webpack/Rspack 支持等功能。另一方面，他们将使用库存 CT 并“免费”获得任何 CT 改进，因此可以为这两种方法提出论据。

我同意这里有很多重叠之处。当我们探索这个领域时，我们绝对有兴趣进行合作。我们推荐的 CT 方法（Storybook Test Runner）已经基于 Playwright，并且我们是它的忠实粉丝。

@pavelfeldman @sand4rt 非常感谢您的来回。我将根据我们的讨论修改 PR。我将采取不同的方法，允许 Storybook 用户在“纯”CT 测试中重用他们现有的故事 React/Vue/Svelte/etc 组件。这与我们对 Storybook 的愿景一致，也使 Playwright CT 更容易被庞大的 Storybook 社区所访问。

我支持上面关于 CT 缺乏构建器和元框架功能支持的大部分批评。如果有机会在这个方向上进行合作，我很乐意继续围绕重新使用 Storybook 作为 CT 渲染引擎进行对话。我和团队对任何其他类型的协作感兴趣，例如共享包等，因此我们也会对此进行考虑。

与此同时，我会将其转化为一个小型文档更新，为用户提供使用标准 API 集成这两个工具的明确方法。这应该会让用户受益，并以有用的方式推动这两个项目向前发展。我正在将 PR 转为草稿状态，并在我们这边准备好更改后再次尝试。

惊人的！这也正是我的想法。

我只是这里的贡献者，但我希望将来在这方面进行合作，看看有什么可能性。如果你问我的话，现在还为时过早，因为 Playwright 组件测试仍处于实验阶段。

React 测试库似乎正在开发 Next/server 渲染器 BTW https://github.com/testing-library/react-testing-library/issues/1209：。也许这对于共享包来说是一个好的开始？（这里只是大声思考）

好的！这一定会对想要使用Playwright CT + Storybook的用户有所帮助，期待:)

:wave: @shilman 你对这个 PR 有何计划？您想移动下面的部分并定位 Storybook 用户吗？如果您选择这样做，请更新补丁并删除草稿标志，以便我们可以继续！

@pavelfeldman 抱歉回复慢了——我正和我的孩子一起回湾区，这真是一个磨难。

事实证明，由于https://github.com/microsoft/playwright/issues/17957，让我们的便携式故事与 Playwright 合作（讽刺的是？）存在一些问题

一旦解决了这个问题，我将关闭此 PR 并打开一个新的 PR。谢谢你的耐心！

读完这篇文章后，我有点不清楚目前测试故事的最佳方法是什么。鉴于 Storybook 的受欢迎程度，我知道很多团队/公司都编写了自己的古怪集成来测试它们，但没有一个是理想的。如果能有一些官方防弹的东西让每个人都能从中受益，那就太好了。

https://github.com/storybookjs/playwright-ct看起来很棒，但已存档，因此不确定是否应该使用抄送 @shilman 。

play就我个人而言，我在我的故事中使用该函数，并使用https://github.com/storybookjs/testing-library（在幕后使用 playwright）对其进行测试。

@Meemaw 我们推荐 Storybook Test Runner作为测试故事的最佳方式。它也是基于剧作家。我将记录一种使用 Playwright CT 进行测试的方法，但它需要对 Storybook 和 CT 进行一些更新。

@shilman 你好 Shilman，我喜欢使用这个@storybookjs/playwright-ct图书馆。它/iframe.html?id=xxx通过提供语法糖提供了一种便捷的使用方式。此外，它还支持使用事件回调，从而大大简化了开发。图书馆会解档吗？

我认为 Storybook 是一个可交付成果，使我们能够显示组件“故事”，并且与 Test Runner 相比，Playwright 提供了卓越的 IDE 集成。 @storybookjs/playwright-ct 充当连接这两个强大工具的桥梁。

@tmkx，我们将采用不同的集成方法，这应该提供几乎同样好的体验，而故事书方面的维护要少得多。准备好后我会在这里分享，希望在第四季度晚些时候