同一個系統要維護兩個版本的對外介面,還要跟一個不受自己控制的外部系統交換資料。這個系列從一套真實運作中的 Laravel 專案的 63 支測試檔案出發,記錄測試分層怎麼設計才有意義:哪一層的失敗該讓你立刻知道是自己程式壞了,哪一層只是外部系統的資料長得跟預期不一樣。涵蓋 Unit/Feature 測試分層、測試替身設計、外部 SOAP 服務的整合測試手法,以及幾次「測試通過但沒有真的驗證到東西」的真實踩坑紀錄。
前言 「要測試一段字串清洗邏輯,是不是要把清洗前後的每個字元都比對過一次?」 今天要看的是這個系統處理外部系統傳回的髒 XML 資料時,用的一種很精簡的測試手法...
前言 「這支測試已經綠燈很久了,應該沒問題吧?」 這句話最危險的地方在於,它把「測試綠燈」直接等同於「這段邏輯真的被驗證過」。今天要拆一個真實發生過的案例:一支...
前言 「昨天不是已經測過遷移指令了嗎?今天還要再測一次檔案路徑?」 昨天測的是「遷移指令這整個流程」——它能不能正確找到舊格式的檔案、能不能正確搬到新路徑。但如...
前言 「這支測試昨天明明是綠燈的,今天怎麼突然紅了?」 如果你的測試依賴「現在幾點」來決定行為——例如抓「過去兩天」的資料、判斷某筆紀錄是不是「已經超過一週沒更...