這個系列並非教你寫程式,但是希望你能夠「看懂」。理由很直接: AI 產出的測試到底會不會抓問題,得有人判斷,那個人是你。好消息是,看懂比會寫容易非常多, 就像看懂菜單不需要會做菜。這篇要介紹 Playwright測試的骨架, 文末會附一組練習, 讀者看完後可以自己驗收。

把第 2 篇的測試攤開

第 2 篇 Claude Code 幫你寫的測試,大概長這樣(你的版本用字可能略有不同):

import { test, expect } from '@playwright/test';
 
test('homepage title', async ({ page }) => {
  await page.goto('https://playwright.dev');
  await expect(page).toHaveTitle(/Playwright/);
});

圖 1:測試骨架逐行解剖

跟著圖上的編號逐行看。圖已經講了每行是什麼,下面只補幾個「看起來很程式」的符號,各一句話:
• ① 的 import:固定開場白,看過一次,以後跳過。
• ② 的 async 和箭頭 =>:固定寫法,意思接近「接下來是一段會花時間的流程」。認得就好,不用會寫。
• ③④ 的 await:「等這步做完,再往下」。動作前面幾乎都有。
• ④ 的 /Playwright/:兩條斜線夾住的叫正規表達式,在這裡就是「包含這個字樣」。不用深究。
• ⑤ 的 });:收尾括號,跟 ② 的開頭成對,永遠一起出現。

整個結構用一句話總結:每個測試都是一組動作,加上至少一個驗證。動作(goto、click、fill)讓網頁到達某個狀態, 驗證(expect 那行)檢查狀態對不對。讀任何 Playwright 測試,先找 expect 在哪裡,那是這個測試存在的理由。

高頻詞彙表

認得下面這幾個,八成的測試就讀得動了:
• test(...):宣告這是一個測試,引號裡是名稱,會出現在報告上。之後還會看到 test.describe(...),那是把一群相關測試包成一組,像資料夾。
• page:一個瀏覽器分頁。所有對網頁的操作都是 page 開頭: page.goto 前往網址、page.click 點擊、page.fill 填字。
• await:等這個動作做完再繼續。幾乎每行動作前面都有,閱讀時直接跳過。不過哪天看到某行動作沒有 await,值得問一句為什麼,漏掉它是常見的隱形 bug。
• expect(...):斷言,也就是驗證。expect(page).toHaveTitle(...) 照英文唸就是意思:期望這個頁面有這個標題。
• locator、getBy 開頭的那些:定位,找到畫面上的某個東西。第 6 篇的主角,先眼熟。

有沒有發現,Playwright 的命名刻意寫得像英文句子:toHaveTitle、toBeVisible、toContainText,照字面唸出來就是它的意思。你的英文閱讀能力,可以直接折抵一部分程式閱讀能力。唸不通的,丟給 Claude Code 問「這行翻成中文是什麼意思」, 通常都能讓你瞬間明白, 原來這段程式在做什麼。

看懂的三個層次

圖 2:程式閱讀能力的三個層次

• 層次一,看懂結構:分得出哪些行是動作、哪一行是驗證。讀完這篇你大概就有這個層次的能力。
• 層次二,看懂意圖:能用一句話說出這個測試在驗證什麼行為。接下來幾篇看多了,自然會到。
• 層次三,判斷對錯:看得出 AI 寫的斷言跟你的測試意圖有沒有落差。例如你要驗「訂單成立」,它只驗了「按鈕被點擊」。
• 把關用的是層次二和三,而這兩層考的是測試思維,不是語法。這就是為什麼不會寫程式,不妨礙你當把關的人。

練習:自己驗收一下

讀下面這段測試,先別往下看,用一句話說出它在驗證什麼:

test('add todo', async ({ page }) => {
  await page.goto('https://demo.playwright.dev/todomvc');
  await page.getByPlaceholder('What needs to be done?').fill('買牛奶');
  await page.keyboard.press('Enter');
  await expect(page.getByTestId('todo-item')).toHaveCount(1);
});

答案:在待辦清單新增「買牛奶」,清單應出現 1 筆。你的答案用詞不同沒關係,重點是有沒有抓到動作是新增、驗證是筆數。這段用的是官方示範站,可以請 Claude Code 建檔真的跑一次,綠燈會回答你讀得對不對。

接著練層次三:這個測試有什麼盲點?想一下再往下。

可以挑的點有幾個。只驗筆數、沒驗內容,清單裡出現的是別的字也會過。新增第二筆時筆數就不是 1,測試之間會不會互相影響。能挑出任何一點,你的層次三已經在萌芽。

一個便宜又有效的習慣

從今天起,每次 Claude Code 產出測試,花三十秒找到 expect 那幾行,問自己:它驗證的,是我要驗證的嗎?不確定就直接問它:

你可以這樣對 Claude Code 說:

這個測試的斷言在驗證什麼?如果功能壞掉但這個斷言仍然會通過,可能是什麼情況?

第二個問題特別有殺傷力,它逼 AI 自己說出這個測試的盲點。你會慢慢發現,審查 AI 的產出,用的就是你原本的測試設計思維,只是對象從功能變成了測試本身。