測試基礎入門：為什麼寫測試、何時開始測試，以及世界上最簡單的測試
你的程式碼一定會被測試，差別只在誰來測
講師 Steve Kinney 在開場就點出一個前提，程式碼永遠會被測試，唯一的差別是由誰來測。要嘛是開發者自己測，要嘛是使用者在正式環境幫你測，用半夜跳出來的告警、堆積如山的 bug report 來測。測試可以手動進行，也可以交給自動化系統執行，這門課的目標就是帶大家走向後者，讓「確認程式碼還能正常運作」這件事自動發生。
寫測試不難，難的是把程式碼寫成容易測試的樣子
Steve 開宗明義提出一個核心信念，寫測試本身其實不難，只要會寫 JavaScript，大概就有能力上手測試。真正困難的不是測試技巧，而是有些程式碼本身很難測試。當一段程式碼難以測試時，需要的往往不是把測試功力練得更強，而是把程式碼拆開、重新組織，讓它變得可測。
這門課因此同時處理兩件事，一是實際動手寫測試，二是練習把既有程式碼調整成更容易測試的形態。有時候會先寫測試，再回頭修改程式碼，看看怎麼讓後續維護更輕鬆；也有時候會直接面對已經很難測試的程式碼，因為現實中不是所有程式碼都是自己從零打造的，可能是接手別人的專案、使用的第三方套件，或者是三個月前的自己寫下、現在已經看不懂的產物。
課程沒有前置知識門檻
課程不預設任何測試經驗，也不要求熟悉特定框架。內容會用到一些 React 與 Svelte 元件，但重點始終放在測試這件事本身，框架只是拿來示範測試手法的載體，因為現實工作中經常會遇到這些框架。
什麼時候該開始學測試
有學員提問，程式學習到什麼階段，才是開始關注測試的好時機。
Steve 的答案是，大約從能寫出一兩個可以正常運作的函式開始，就是進場的好時機。測試本身沒有特別困難的門檻，只要能寫 JavaScript、能執行腳本並在終端機或頁面上看到結果，就已經具備開始測試的基礎。至於什麼時候「必須」學，取決於專案規模，如果只是一個小腳本，盯著 console log 檢查可能就夠用了。
真正判斷「現在需要測試」的訊號，是一種特定的焦慮感，當你要修改一段程式碼，卻不確定會不會連帶弄壞其他東西、不確定自己引入了什麼 regression 的那種存在性恐懼。測試的核心目的，就是消除這種修改程式碼時的恐懼，盡可能讓開發者對自己的程式碼有信心，即使邊界案例有時仍會讓人意外。能夠放心修改程式碼、同時大致確信沒有搞砸別的地方，就是測試想達到的標準。這也是為什麼要測試，為了晚上能睡得著，為了開 PR 時不用擔心同事會因為你弄垮 production 而在一週後恨你。當你發現要在腦中同時記住的東西太多、希望有東西能自動幫你把整個應用「踢一踢輪胎」確認沒壞掉時，就是測試真正變得有用的時刻。
測試驅動開發：先寫測試，讓程式碼自然變得好測
Steve 接著簡單帶到測試驅動開發（Test-Driven Development，TDD）的概念，先寫測試，再讓它通過。這個做法呼應了前面提到的兩難，寫測試不難，難測的程式碼才難。如果你在寫程式碼之前先寫測試並讓它通過，幾乎很難寫出難以測試的程式碼，因為每一步都是先講清楚「我希望這件簡單的事情成立」，通過之後才前進下一步。這個紅燈變綠燈、一步步推進的過程，也帶來持續的小小成就感，幫助我們在寫程式碼的同時，順便釐清邏輯是否合理。
簡單來說，只要能寫一點基礎 JavaScript，就是學測試的好時機，因為測試做的事，就是自動驗證程式碼的行為是否符合預期。當手動反覆確認的時間成本已經超過寫測試的成本時，就是該開始寫測試的時候了。
世界上最簡單的測試
在正式開始之前，Steve 先展示一個最基本的測試範例，說明測試的組成元件。
javascript
import { it, expect } from 'vitest';
it('is a super simple test', () => {
expect(true).toBe(true);
});測試說到底就是 JavaScript。這裡用的函式叫 it（也可以叫 test），接受一個描述測試內容的字串，第二個參數則是一個函式，裡面對「這個世界」做出一些斷言（statement）。上面這個例子幾乎不可能失敗，本身沒有實際意義，但已經具備測試的核心結構。
接著把斷言換成真正驗證邏輯的內容，測試就開始有意義。
javascript
it('is a super simple test', () => {
expect(add(2, 2)).toBe(4);
});這個範例呼叫了一個 add 函式，並驗證回傳結果是否等於預期值。這類看似簡單的加法測試，恰恰是最容易被忽略、卻也最該被驗證的地方，一旦加法邏輯被意外改動，或後續改成用遞迴呼叫加法來實作乘法之類的重構，測試能立刻抓出結果是否還符合預期。
測試執行器（test runner）做的事，就是把這些斷言全部跑過一遍，確認世界運作的方式，真的符合我們認為它應該運作的方式。這就是測試在做的全部事情，不是為了追求百分之百的測試覆蓋率，也不是拿來炫耀的勳章，而是單純為了對自己的程式碼有信心，確信修改之後，大概率沒有弄壞什麼。
此文章是 FrontendMasters 上的 Testing Fundamentals 課程筆記
