好測試的三支柱：可信賴與可維護 (Pillars of Good Unit Tests)

// 預期值是「算」出來的：把 production 的組字串邏輯抄進了測試
test("build message from user and greeting", () => {
  const user = "USER";
  const greeting = "GREETING";
  const actual = MessageBuilder.build(user, greeting);
  expect(actual).toBe(user + " " + greeting); // ← 若 build() 的拼接有 bug，這裡也會用同樣的錯法算，照樣綠燈
});

測試複製了待測程式的邏輯。萬一 build() 的拼接規則寫錯，這個測試會用「同一種錯」去對答案，於是永遠抓不到 bug。

test("build message from user and greeting", () => {
  const actual = MessageBuilder.build("user", "greeting");
  expect(actual).toBe("user greeting"); // ← 寫死的預期值，不參與任何計算
});

預期值是人腦手算、直接寫死的常數。測試不再重複 production 的邏輯，才能真正扮演「另一雙眼睛」。若工具方法裡真的躲不掉複雜邏輯，那就連工具方法也要寫測試。

test("isValid returns true and remembers the last call", () => {
  const analyzer = makeDefaultAnalyzer();
  expect(analyzer.isValid("abc")).toBe(true); // 關注點 A：回傳值
  expect(analyzer.wasLastCallValid).toBe(true); // 關注點 B：狀態變更 —— A 一失敗，這行永遠不會跑
});

多數框架在第一個斷言失敗時就拋例外，後面的斷言根本不執行——B 到底是好是壞，你毫無資訊。而且這種測試也很難取一個準確的名字。

test("isValid returns true for a valid name", () => {
  const analyzer = makeDefaultAnalyzer();
  expect(analyzer.isValid("abc")).toBe(true);
});

test("isValid remembers that the last call was valid", () => {
  const analyzer = makeDefaultAnalyzer();
  analyzer.isValid("abc");
  expect(analyzer.wasLastCallValid).toBe(true);
});

判斷準則很簡單：如果第一個斷言失敗了，你還在乎第二個嗎？在乎，就該拆。 拆開後每個測試名字就是一句規格，紅燈時直接告訴你哪個關注點壞了。

// 問題一：斷言內部私有狀態（分隔符），那是隨時會變的實作細節
test("initialize sets the default delimiter to tab", () => {
  const log = new LogAnalyzer();
  expect(log.getInternalDefaultDelimiter()).toBe(null);
  log.initialize();
  expect(log.getInternalDefaultDelimiter()).toBe("\t"); // ← 測的是內部契約，不是公開功能
});

// 問題二：用 stub 餵假資料，卻又斷言 stub「被呼叫過」
test("analyze looks up an unknown user", () => {
  const fakeData = { getUserByName: () => null }; // 本意只是餵輸入（stub）
  const analyzer = new LogAnalyzer(fakeData);
  analyzer.analyze("UserNameThatDoesNotExist");
  expect(fakeData.getUserByName).toHaveBeenCalled(); // ← 把 stub 當 mock 用，鎖死了內部演算法
});

兩者都在鎖定「內部怎麼做」：內部分隔符、內部有沒有呼叫某方法。只要重構換個實作、功能不變，測試就無辜地紅了。stub 只該餵輸入、不該被斷言（見 測試替身：Stub vs. Mock）。

// 只透過 public API 驗最終行為，不碰內部狀態
test("analyze parses tab-delimited fields", () => {
  const log = new LogAnalyzer();
  const output = log.analyze("10:05\tOpen\tRoy");
  expect(output.fields).toEqual(["10:05", "Open", "Roy"]); // 公開結果，實作可自由改
});

// 只需要「包含」時就別要求「完全相等」或「在特定位置」
test("summary mentions the user name", () => {
  const summary = report.buildSummary("Roy");
  expect(summary).toContain("Roy"); // contains，而非 equals 整段固定字串
});

只要最終值對，就不該過問內部是否呼叫了誰。需要部分匹配時用 contains／集合的「包含」檢查，而不是強求精確、順序、位置——少一分不必要的約束，就少一分無謂的脆弱。

const person = new Person(); // ← 兩個測試共用同一個實例（共享狀態）

test("finds a phone number starting with 055", () => {
  person.addNumber("055-4556684");
  expect(person.findPhoneStartingWith("055")).toBe("055-4556684");
});

test("returns null when no number exists", () => {
  expect(person.findPhoneStartingWith("0")).toBe(null); // ← 會紅：Test1 已經加了號碼進去
});

第二個測試的成敗被第一個測試綁架，甚至取決於執行順序。多數框架不保證測試順序，於是這種測試時好時壞——隔離性一破，信賴性也跟著沒了。

// helper / factory method：集中建立與初始化，語意一變只改這一處
function makeAnalyzer() {
  const analyzer = new LogAnalyzer();
  analyzer.initialize();
  return analyzer;
}

test("finds a phone number starting with 055", () => {
  const person = new Person(); // 各自全新實例，互不干擾
  person.addNumber("055-4556684");
  expect(person.findPhoneStartingWith("055")).toBe("055-4556684");
});

test("returns null when no number exists", () => {
  const person = new Person();
  expect(person.findPhoneStartingWith("0")).toBe(null);
});

每個測試自備狀態、用完不留殘渣。重複的建構邏輯抽進 factory／helper（而不是塞進共享的 setup），這樣讀者在測試本體就能看到完整情境，語意改變時也只改一處。