Storybook是用于构建组件驱动的用户界面的行业标准工具。它能够实现结构化的UI开发、文档和测试。
我很高兴能与大家分享Storybook的超强测试功能的预览。故事捕捉你的组件的关键状态。像Shopify、Adobe和O'Reilly Media这样的领先团队已经在他们的测试文件中导入故事，以扩大UI测试的覆盖面。现在，这个工作流程被直接内置到Storybook中。
Storybook交互测试允许你在故事本身中编写交互脚本和检查预期。这使你能够在开发UI的相同环境中运行功能测试：浏览器：
- ✅在真实的浏览器中运行
- ⚡️无需等待，也没有片断
- 🐙由测试库提供技术支持
- 🔗用一个URL重现错误
- 🔍 快速调试
- 🛠 低维护性
等等，但为什么？
Storybook的核心创新是 "故事 "结构。只需很少的努力，你就可以捕捉到你的组件所支持的每一个状态。
故事就像测试一样，但是对于UI来说。它们代表了你的组件在通过道具和上下文等静态输入时应该如何呈现。这种级别的粒度简化了对UI错误来源的调试，消除了flake，而且写起来很自然。
但是，如果你想测试交互式组件的行为--真正的用户是如何与一个组件接触的呢？
目前，你需要将故事导入测试工具来编写额外的交互。或者你会运行一个笨重的QA套件并重复测试案例。在这两种情况下，你可以用更多的时间来维护一个测试套件，而不是真正地编写测试。
如何防止损坏的UI
想象一下，如果你可以在同一个地方建立UI和测试UI？如果你的组件包括对它们应该如何表现的期望，你会在它们损坏的瞬间知道。
故事书的交互测试对用户界面进行了测试，以模拟用户行为。它们在幕后运行，在代码改变导致组件行为不正常时通知你：
// FormExample.stories.js|tsx
import { expect, screen, userEvent } from '@storybook/addon-test';
export default { component: FormExample }
export const Empty = {};
export const Filled = {
...Empty,
play: async () => {
await userEvent.type(screen.getById('user'), 'shilman@example.com');
await userEvent.type(screen.getById('password'), 'blahblahblah');
await userEvent.click(screen.getByText('Submit'));
await expect(handleSubmit).toHaveBeenCalledWith({
user: 'shilman@example.com',
password: 'blahblahblah',
});
}
}
用于UI测试的Storybook
我们与Shopify、华盛顿邮报、Adobe以及更大的Storybook社区的团队进行了交流。很明显，开发人员必须测试组件的行为，但却被笨重的QA工具和flake所困住。
UI测试应该是快速而简单的。 Storybook允许你在故事本身中编写交互测试。 每当你点击保存，你的测试就会运行。
交互和期望的播放功能
交互测试是使用组件故事格式的 play 功能来解锁的。播放功能是一个小的代码片段，在故事被渲染后执行。它允许你：
- 在真实的浏览器中编写用户交互的脚本
- 用断言/期望值验证行为
- 组成互动以减少维护负担
考虑一个有4个故事的例子：RangeSlider 组件。为了检查它是否工作正常，你必须输入价格或拖动手柄来改变平均价格。这就是播放功能的闪光点：
当每个故事被渲染时，播放功能会运行交互和期望。测试结果会在瞬间出现，就在你的故事旁边：
用于调试的回放控制
交互 "面板将播放功能中的每个交互可视化，并包括用于重现每个步骤的回放控制。
点击一个步骤，跳到用户事件执行时你的组件的确切状态。
使用回放控制来观察步骤之间的中间状态。或者重放所有故事的步骤，以仔细检查交互测试是否按预期工作。
无需剥落，无需等待
交互测试在真实的浏览器中运行，使用你提供给终端用户的真正的DOM元素。由于用户界面与后端问题隔离，堆栈的其他部分的错误不会触发假阳性结果（剥落！）。
更重要的是，Storybook交互测试以JavaScript的执行速度（几毫秒）运行，因为UI需要渲染的所有数据已经在客户端。
由测试库提供支持
Storybook交互测试由测试库提供支持，可在你最喜欢的命令行工具（如Jest和Playwright）中运行。我们不是在重新发明轮子；我们的目标是在现有的最佳实践基础上提供对开发者友好的人体工程学。
方便复制的Permalinks
Storybook是一个网络应用，可以在你的本地开发环境或静态主机上运行。故事书的状态总是被编码在它的URL中。
这意味着你可以向队友发送一个URL来重现确切的测试错误--即使他们没有本地的开发环境。错误也包括相关的环境信息。
这与QA工具不同，QA工具需要一个额外的应用程序来执行测试和调试。故事书的测试可以在你已经使用的浏览器和开发工具中开箱即用。
没有API锁定
组件故事格式可以编译成JavaScript模块。当你编写故事时，你正在投资于作为标准的JavaScript。
CSF与整个生态系统是兼容的。例如，你可以用Chromatic（由Storybook维护者编写）验证故事的外观，用Axe验证可访问性，用Lighthouse验证性能。
