Lecture 07A（上）：JUnit 測試與測試驅動開發

到目前為止我們用 加一個 來檢查程式。它能用，但有三個問題： 所有檢查擠在一個方法裡，第一個失敗就會讓後面的全部跳過；沒有統一的報告； 而且很難「對同一份契約測多種實作」。JUnit 是 Java 世界的標準測試框架，正好解決這三件事。

為什麼要寫自動化測試？

• 回歸保護（regression）：每次修改後一鍵重跑，立刻知道有沒有弄壞以前能動的東西。

• 可執行的規格：測試把介面註解裡的前置／後置條件變成會跑的程式，比文字更精確、永不過時。

• 設計回饋：難以測試的程式通常也難以使用；先寫測試會逼你把介面設計好。

JUnit 5 入門

一個 JUnit 測試就是一個標了 的方法。JUnit 會自動找到所有這樣的方法、逐一執行、統計結果：

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;   // assertEquals、assertTrue…

class CalculatorTest {
    @Test
    void additionWorks() {
        assertEquals(4, 2 + 2);                       // (預期值, 實際值)
    }
}

常用的斷言（都在 ）：

每個斷言都可以多接一個字串參數當失敗訊息：。

案例： 的黑箱測試

Lecture 07A 的主角是「賓客名單」——一個集合語意的 ADT：一個人要嘛會來、要嘛不會來， 同一個人 兩次等於 一次。

public interface GuestList {
    void add(String name);          // 記錄某位賓客會來
    void remove(String name);       // 記錄某位賓客不來了（原本不在名單上則什麼都不做）
    boolean isComing(String name);  // 該賓客目前是否會來
    int count();                    // 目前會來的人數（不重複計算）
    String[] coming();              // 會來的名字（防禦性複製）
}

測試只認識這個介面。為了讓同一套測試能套用到多種實作，我們把測試類別寫成抽象的， 把「要測哪一種實作」交給一個抽象的工廠方法：

abstract class GuestListTest {

    abstract GuestList create();            // 由子類別決定要測哪一種實作

    private GuestList gl;

    @BeforeEach
    void setUp() {
        gl = create();                       // 每個測試開始前都拿到一份全新的空名單
    }

    @Test
    @DisplayName("新名單是空的")
    void emptyListHasNobody() {
        assertFalse(gl.isComing("Fabian"));
        assertEquals(0, gl.count());
        assertEquals(0, gl.coming().length);
    }

    @Test
    @DisplayName("集合語意：同一個人 add 兩次等於 add 一次")
    void addingTwiceIsIdempotent() {
        gl.add("Fabian");
        gl.add("Fabian");
        assertTrue(gl.isComing("Fabian"));
        assertEquals(1, gl.count(), "重複加入不應被重複計算");
        gl.remove("Fabian");
        assertFalse(gl.isComing("Fabian"), "移除一次之後必須完全消失");
        assertEquals(0, gl.count());
    }

    @Test
    @DisplayName("coming() 回傳的是防禦性複製，改它不影響名單")
    void comingReturnsDefensiveCopy() {
        gl.add("Fabian");
        gl.add("Nicholas");
        String[] snapshot = gl.coming();
        snapshot[0] = "Intruder";                       // 惡意（或不小心）改動回傳的陣列
        assertFalse(gl.isComing("Intruder"), "封裝：外部改動不得影響內部狀態");
        assertEquals(2, gl.count());
    }

    @Test
    @DisplayName("assertThrows 示範：null 名字不合法")
    void nullNameIsRejected() {
        IllegalArgumentException e =
                assertThrows(IllegalArgumentException.class, () -> gl.add(null));
        assertNotNull(e.getMessage());
    }
    // ……共 9 個測試：remove 只影響該人、從空名單 remove、移除後再加、1000 人觸發倍增……
}

class LazyGuestListTest extends GuestListTest {          // 對「懶惰」實作跑整套測試
    @Override GuestList create() { return new GuestArrayList(); }
}
class StrictGuestListTest extends GuestListTest {        // 對「嚴格」實作跑同一套測試
    @Override GuestList create() { return new GuestArrayUniqueList(); }
}

兩種實作，一套測試

「懶惰」實作 的 不檢查重複，直接塞進陣列；重複要等 時一次清光， 則只在名字「第一次出現」時計數：

public class GuestArrayList implements GuestList {
    String[] data = new String[2];       // package-private：子類別可直接存取
    int used = 0;                        // data[0..used-1] 是「用過」的格子（可能含 null 洞與重複）

    @Override
    public void add(String name) {
        if (name == null) throw new IllegalArgumentException("賓客名字不可為 null");
        if (this.used == this.data.length) {          // 滿了：換一個兩倍大的陣列
            String[] old = this.data;
            this.data = new String[this.used * 2];
            for (int i = 0; i < this.used; i++) this.data[i] = old[i];   // O(n) 複製
        }
        this.data[this.used] = name;
        this.used = this.used + 1;
    }

    @Override
    public int count() {
        int n = 0;
        for (int i = 0; i < this.used; i++) {
            if (this.data[i] != null && indexOf(this.data[i]) == i) n = n + 1;   // 只數第一次出現
        }
        return n;
    }
    // remove：掃完整個陣列，把所有同名都設成 null；isComing：線性搜尋；coming：複製到新陣列
}

「嚴格」實作 繼承它，只改 （先查 ）， 因而多了一條不變量「非 null 的名字互不相同」，於是 找到第一個就能停、 不必查重。 兩者對外行為完全一致——是 LSP 合規的子型別——所以 18 個測試（9 × 2 種實作）全部通過：

Test run finished after 185 ms
[         5 containers found      ]
[         5 containers successful ]
[        18 tests found           ]
[        18 tests started         ]
[        18 tests successful      ]
[         0 tests failed          ]

測試驅動開發

用 走一遍 TDD 的前三圈：

1. 紅：寫 。此時 連類別都沒有，編譯失敗也算「紅」。 綠：建立類別， 直接 、 直接 。通過。

2. 紅：寫 （add 之後 isComing 為 true）。寫死的 失敗。 綠：加上陣列與 ， 存進去， 線性搜尋。

3. 紅：寫 。 回傳 2，失敗—— 這個測試逼我們決定：是在 時擋重複（嚴格），還是在 ／ 時處理（懶惰）？兩條路都通，於是有了兩種實作。 重構：兩種實作共用的程式碼抽到父類別。

防禦性複製

若直接 ，測試 會失敗：呼叫者改陣列就等於改名單內部。 規則很簡單：

String[] copy = new String[count()];      // 全新陣列
// ……把非 null 且第一次出現的名字複製進去……
return copy;                              // 呼叫者改 copy 不影響 data

// 第 3 節的另一個例子：
public List<String> getLog() { return new ArrayList<>(this.log); }

陣列倍增：為什麼滿了要「乘二」而不是「加一」？

在陣列滿時把容量加倍。每次放大都要 \(\bigO{n}\) 複製，聽起來很貴， 但因為容量呈 \(2, 4, 8, 16, \ldots\) 成長，放大的次數只有 \(\log_2 n\) 次， 把總複製成本平均到每一次 上，每次只多付常數——這叫攤銷 \(\bigO{1}\)。 若改成每次只加一格，每次 都要複製整個陣列，\(n\) 次 就變成 \(\bigO{n^2}\)。 完整的分析（含圖）在第 [sec:amortised] 節，因為雜湊表的擴容用的是一樣的道理。

在命令列執行 JUnit

IntelliJ 會自動處理 JUnit；若想在終端機執行，下載 JUnit 的獨立執行檔（一個 jar）即可：

$ cd code/05_junit_tdd
$ curl -LO https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone/1.12.2/junit-platform-console-standalone-1.12.2.jar
$ javac -cp junit-platform-console-standalone-1.12.2.jar *.java
$ java -jar junit-platform-console-standalone-1.12.2.jar execute --class-path . --scan-class-path

練習