單一真值來源 或 單點故障

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