TEST-DRIVEN DEVELOPMENT
不是AI寫完才測：
用 Red、Green、Refactor 學會可靠的 Python 程式設計
先定義成功，再讓程式與AI一起追上來。
生成式AI可以快速寫出Python程式，但「看起來能執行」不等於「真的符合需求」。在大三的Python程式實習中，我們要學習一種更可靠的工作方式：先寫測試，再寫程式，最後整理程式。這就是測試驅動開發（Test-Driven Development，簡稱TDD）。
一、什麼是 Red、Green、Refactor？
1. Red：先寫一個會失敗的測試
Red代表「紅燈」。在還沒有功能程式之前，先把我們期待的結果寫成測試。因為功能尚未完成，測試理應失敗；這正好證明測試真的有在檢查需求。
例如，我們要撰寫一個函式，計算一組成績的平均值。先定義成功條件：輸入[80, 90, 100]時，結果應該是90。
def test_average_of_three_scores(): assert average([80, 90, 100]) == 90
此時average()尚未建立，執行測試會失敗。這不是挫折，而是我們明確知道：下一步要完成的是什麼。
2. Green：用最少的程式碼讓測試通過
Green代表「綠燈」。現在才開始寫功能程式，目標是讓剛才的測試通過。此階段不必急著追求最漂亮、最完整的寫法，而是先讓需求正確實現。
def average(scores): return sum(scores) / len(scores)
再執行一次測試，若結果通過，就代表程式至少符合目前定義的基本需求。
3. Refactor：整理程式，但不能改變原本行為
Refactor代表「重構」。當測試已經通過，我們可以安心改善程式的可讀性與可維護性，例如取清楚的名稱、抽出重複程式、補上輸入檢查或撰寫註解。
def average(scores): """計算成績平均；空串列不允許計算。""" if not scores: raise ValueError("成績不可為空") total_score = sum(scores) student_count = len(scores) return total_score / student_count 重構後，原本的測試仍必須通過。也就是說，程式的內部結構可以變好，但對使用者而言，正確行為不能被改壞。
二、為什麼要先測試，再請AI寫程式？
如果直接對AI說「幫我寫一個平均成績的程式」，AI可能產生看似正確的答案；但它不一定知道您如何處理空白資料、文字輸入、缺考成績或小數點。若先把需求寫成測試，就能把模糊的想法變成可驗證的規格。
| 直接請AI寫程式 | 先寫測試，再請AI協作 |
|---|---|
| 容易只看程式能不能執行。 | 先確認程式是否符合明確需求。 |
| 需求改變時，不容易知道哪裡受影響。 | 新增測試即可描述新需求，再修改程式。 |
| AI產生錯誤時，常難以察覺。 | 測試失敗會立即指出程式尚未達標。 |
| 修改後可能不小心破壞舊功能。 | 所有舊測試都能協助確認原有功能仍正確。 |
三、用AI進行TDD的實作方式
在Python程式實習中，可以依照下列流程與AI協作：
- 先用自己的話寫下需求與成功條件。
- 先完成一至兩個測試案例，例如正常資料、空白資料或錯誤輸入。
- 把測試與需求交給AI，請它只修改功能程式，直到測試通過。
- 請AI解釋每一行程式，而不是只複製答案。
- 要求AI協助重構後，再次執行所有測試。
- 由自己檢查輸出結果是否符合常識與真實情境。
四、從「平均成績」到真實專題
TDD不只適合成績計算。未來同學處理YouBike資料、感測器資料、社區問卷、智慧農業資料或網站API時，都可以先寫下「資料正確時應得到什麼結果」，再開始撰寫程式。
- 資料缺少某個欄位時，程式是否能顯示清楚錯誤？
- 感測器數值超出合理範圍時，是否會產生警示？
- API沒有回傳資料時，系統是否仍能安全處理？
- 修改功能後，原本已經成功的功能是否仍能正常運作？
Red、Green、Refactor讓我們更有能力寫出可信任的程式。
國立虎尾科技大學｜Python程式實習
沒有留言:
張貼留言