iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 27
1
Modern Web

玩轉 Storybook系列 第 27

玩轉 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


上一篇
玩轉 Storybook: Day 26 Design System for Developers - Intro、Architecture、Build
下一篇
玩轉 Storybook: Day 28 Design System for Developers - Document
系列文
玩轉 Storybook30

尚未有邦友留言

立即登入留言