玩转 Storybook: Day 27 Design System for Developers - Review、Test

单一真值来源 或 单点故障

Single Source of Truth (SSOT) 单一真值来源

Single Points of Failure (SPOF) 单点故障

简单的记法就是「对，一定是它对；错，一定是它错」

对於 Frontend 团队来说，Design System 就是这样一个角色。如果改变了纳入Design System的元件，它会改变相依的APP。所以任何变更都会造成风险，就像滚雪球一样。

和团队一起对UI元件做视觉审查

视觉审查是确认UI功能和外观的过程。大多数开发人员都熟悉Code Review，收集程序码反馈後提高程序码质量。UI元件则是以图形方式呈现，进行视觉审查，可用以收集 UI/UX 的反馈。

建立协同合作的通用参考点

删除node_modules、重新安装Package，清除LocalStorage和Cookies。如果听起来这些动作很熟悉，您就会知道确保团队成员参考最新的程序码是多麽困难。当没有相同的开发环境时，将本机开发环境中的问题与真正的错误区分开来就是一场噩梦。

幸运的是，作为前端开发人员，我们有一个共同的编译目标：浏览器。精明的团队会在线发布Storybook，以作为视觉审查的通用参考点。这回避了本机开发环境固有的复杂性。

当可通过URL访问实时(当下)的程序码所呈现的UI元件时，相关人员可以从浏览器舒适地确认UI的外观。

每个Pull Request，都发布至Storybook可以使视觉审查更加容易，并帮助产品所有者考虑元件开发。

发布Storybook

使用 Chromatic 做为视觉审查工作流程的工具，它是由 Storybook 的开发者所维护的专案。它允许开发者发布Storybook至云端，且安全地做网站代管。当然开发者也可以发布 Storybook 到其它网站代管的服务，但是 Chromatic 的视觉审查工作流程，有利於快速的做反馈。

Get Chromatic

登入及注册 Chromatic

选择你的 Design System Repo，这将同步访问权限并检测PR检查。

接下来要在 Design System 专案中安装 Chromatic

一旦 Chromatic 安装完成，就可以使用以下指令发布Storybook到Chromatic Cloud上

$ npx chromatic --project-token=<project-token>

发布成功的话，Terminal会显示 Storybook 的拜访站点。

第一次执行时，也会问你要不要把 chromatic 执行指令存到package.json，方便以後快速的发布。

分享 Chromatic 生成的 Storybook 拜访站点给团队成员，团队成员就可以在网站上做 UI 视觉审查

现在，我们已经成功设置了发布到Storybook的基础结构，接下来要设置CI让视觉审查更加自动化。

Continuous integration

在这个范例，使用 GitHub Actions (在适度的使用下，此服务可为免费) 做为 CI 的服务。

在前一个步骤的选择 Design System Repo，Chromatic 已经自动的建立一个名为chromatic.yml的文件，放置在 Repo 的.github/workflows/ 下

# .github/workflows/chromatic.yml

# name of our action
name: 'Chromatic'
# the event that will trigger the action
on: push

# what the action will do
jobs:
  test:
    # the operating system it will run on
    runs-on: ubuntu-latest
    # the list of steps that the action will go through
    steps:
      - uses: actions/checkout@v1
      - run: yarn
      - uses: chromaui/action@v1
        # options required to the GitHub chromatic action
        with:
          projectToken: project-token
          token: ${{ secrets.GITHUB_TOKEN }}

所以当我们对 Design System Repo 推送程序码时，它就会自动的部署建置 Storybook 到 Chromatic

要求团队进行视觉审查

Chromatic 不只是做自动的部署 Storybook，它还是能在开发者发布 Pull Request 时，协助开发团队做视觉审查。确保每一个推送程序码时都不会造成意外的UI变更。

接下来我们就试看看，在新分支上更改UI来演示视觉审查。

Step 1 开发人员针对元件做出修改

$ git checkout -b improve-button

调整Button元件如下

//src/Button.js

// ...
const StyledButton = styled.button`
  border: 10px solid red;
`;
// ...

Step 2 开发人员提交程序码发起 Pull Request

修改完成後，把这个分支推到 Github Remote Repository

$ git push -u origin improve-button

去 Github 建立一个 Pull Request，要准备把 improve-button 这个分支 merge 回主线。

Step 3 开发人员发布 Storybook 至 Chromatic 做视觉审查

再来执行 Chromatic 的 Script， 把 Storybook 推上 Chromatic，让团队成员可以去 Chromatic 做视觉审查

$ npx chromatic --project-token=<project-token>

Step 4 团队成员收到Pull Request通知，准备做Review

团队成员可以在 Chromatic 按下 「Review Change」

Step 5 团队成员依照变动结果，做出审核

因为变化差异太多，审查者认为需要拒绝(Deny)这次变更

透过视觉审查，Pull Reqeust 未能通过。

Step 6 Pull Reqeust 未通过，开发者重新开发

调整Button元件如下

//src/Button.js

// ...
const StyledButton = styled.button`
  box-shadow: 10px 5px 5px black;
  border: 0;
`;
// ...

Step 7 开发人员重新推送修改後的程序码，且再次发布Storybook至Chromatic 做视觉审查

Step 8 团队成员收到通知，再次做Review，依照变动结果，做出审核

Step 9 Pull Reqeust 通过，程序码 Merge 回主线

小结

在专案开发中，大多数的问题都是发生在於沟通不良而不是技术。视觉审查可帮助团队在开发过程中收集持续的反馈，以更快地交付Design System。

测试元件用以保持系统的品质

UI 元件的测试

在开始之前，让我们弄清楚进行测试的意义。Design System由UI元件所组成。每个UI元件都包含Stories，这些Stories描述了给定一组输入（属性）的预期外观。然後由浏览器或设备为End User呈现Stories。

从上图可以发现，网站要达成在每个浏覧器、每种装置尺寸、每个使用者可使用的能力下运作，是一个不容易的工作，我们也无法每次变更都去人工审核，所以自动化测试是非常必要的。

准备测试

视觉测试

为了加速审查，使用 Chromatic 做 UI Review 是推荐的做法。

单元测试

单元测试是给定的输入值，验证程序码是否返回正确的输出。它们与元件并存，可帮助验证特定功能。

元件封装了各种功能，从简单的按钮到复杂的日期选择器。当元件越复杂，仅凭视觉测试捕获细微差别就越棘手。这就是为什麽我们需要单元测试。

例如，我们想测试LINK元件的href属性是否存在并指向正确的位置。这个是视觉测试测不出来的功能

//src/Link.test.js

import React from 'react';
import ReactDOM from 'react-dom';
import { Link } from './Link';

// A straightforward link wrapper that renders an <a> with the passed props. What we are testing
// here is that the Link component passes the right props to the wrapper and itself.
const LinkWrapper = props => <a {...props} />; // eslint-disable-line jsx-a11y/anchor-has-content

it('has a href attribute when rendering with linkWrapper', () => {
  const div = document.createElement('div');
  ReactDOM.render(
    <Link href="https://learnstorybook.com" LinkWrapper={LinkWrapper}>
      Link Text
    </Link>,
    div
  );

  expect(div.querySelector('a[href="https://learnstorybook.com"]')).not.toBeNull();
  expect(div.textContent).toEqual('Link Text');

  ReactDOM.unmountComponentAtNode(div);
});

执行 npm run test 就可以针对我们写的测试脚本做测试

加上 Unit Test 到 GitHub Actions

# .github/workflows/chromatic.yml

# ... same as before
jobs:
  test:
    # the operating system it will run on
    runs-on: ubuntu-latest
    # the list of steps that the action will go through
    steps:
      - uses: actions/checkout@v1
      - run: yarn
      - run: yarn test # adds the test command
      - uses: chromaui/action@v1
        # options required to the GitHub chromatic action
        with:
          # our project token, to see how to obtain it
          # refer to https://www.learnstorybook.com/intro-to-storybook/react/en/deploy/ (update link)
          projectToken: project-token
          token: ${{ secrets.GITHUB_TOKEN }}

无障碍测试

Accessibility 意味着所有人（包括残障人士）都可以理解，导航和与你的应用进行交互，通常他们会使用键盘和屏幕阅读器遍历站点。

根据《残疾人权利公约》，残疾影响人口的15％。Design System对Accessibility的影响很大，因为它们也是UI设计的一部分。改善元件的Accessibility就意味着该元件的每个实例，都能服务到更多人。

在 Storybook 安装 Accessibility Addon

$ npm install -D @storybook/addon-a11y

// .storybook/main.js

module.exports = {
  stories: ['../src/**/*.stories.mdx', '../src/**/*.stories.@(js|jsx|ts|tsx)'],
  addons: [
    '@storybook/addon-links',
    '@storybook/addon-essentials',
    '@storybook/preset-create-react-app',
    '@storybook/addon-a11y',
  ],
};

我们可以在 Accessibility 的 Addon Panel 看到元件是否符合通过无障碍测试。如果没有通过，它也会显示出缺少的部分，让你轻松的以元件的方式开发无障碍的功能。

其他测试策略

测试既可以节省时间，但也会降低维护速度。

在 Design System 比较不合适的测试方法有以下二个

• Snapshot Testing 快照测试

因为它只是比对代码结构的不同，视觉测试在Design System中比快照测试更为适合。

• End-to-End Testing

E2E Testing 适合验证测试复杂的页面流程，Design System是专注元件开发，所以使用 Unit Testing 比较适合。

Next

一个Design System并不仅仅具有测试功能。由於Design System为整个组织的利益相关者服务，因此我们需要教其他人如何从经过良好测试的UI元件中获得最大收益。

接下来的单元会学习如何通过文件来加速设计系统的采用。利用Storybook Docs，可以用较少的工作来创建完整的说明文件。

Reference

Design System for Developers - Review

Design System for Developers - Test