讓測試整潔

是什麼造就一個整潔的測試？三件事，可讀性，可讀性，還是可讀性。

可讀性對於單元測試如此重要，然而是什麼決定了程式碼的可讀性？答案與讓其他程式碼具可讀性的要素一樣：闡明性 (clarity)、簡明性 (simplicity) 及言簡意賅的表達力 (density of expression)。

為了讓程式變得足夠簡潔易讀，在對單元測試持續重構的過程中，作者會漸漸撰寫出一些公用的函式，去幫助測試程式更容易撰寫及閱讀。我們先來看一些作者所寫的程式碼：

@Test
    public void turnOnLoTempAlarmAtThreashold() throws Exception {
        hw.setTemp(WAY_TOO_COLD);
        controller.tic();
        assertTure(hw.heaterState());
        assertTure(hw.blowerState());
        assertFalse(hw.coolerState());
        assertFalse(hw.hiTempAlarm());
        assertTure(hw.loTempAlarm());
    } 

這是一段檢查溫度在「過冷」情況下，各種設備是否自動打開的測試。不必去特別探究細節，這個測試在概念上已算是容易理解，然而作者認為為了查看被檢查的狀態名稱及狀態意義，讀者必須前後來回查看。看到 heaterState，然後回到前方確認為 assertTure (判斷為真)；看到 coolerState，確認為 assertFalse (判斷為假)，這個過程瑣碎且不可靠，於是作者將之重構。

@Test
    public void turnOnLoTempAlarmAtThreashold() throws Exception {
        wayTooCold();
        assertEquals("HBchL", hw.getState());
    } 

很明顯地，可讀性大大提升。然而在提高可讀性的同時，也犧牲了一些東西。

在第三天講到關於變數命名的時候，我們曾說變數要具備意義，這背後其實隱含著一層意義：名稱要具備描述力，就須避免讓讀者看完後還要再思考一遍，接著翻譯成自己明白的語言。換言之，清楚明白才是王道。

然而當我們看到 "HBchL" 這行字串時，沒有人會理解它的意思。但作者認為在這裡使用是恰當的，為什麼？
回到文章的開頭，作者認為測試的整潔，源自於可讀性。一旦當讀者理解字母小寫代表關閉，大寫則表示開啟時，我們就能快速瀏覽過程式碼並了解其結果。
當測試範圍變大時，我們仍能很快速的理解測試的意涵：

@Test
    public void turnOnCoolerAndBlowerIfTooHot() throws Exception {
        wayTooCold();
        assertEquals("hBChl", hw.getState());
    } 

    @Test
    public void turnOnHeaterAndBlowerIfTooCold() throws Exception {
        wayTooCold();
        assertEquals("HBchl", hw.getState());
    } 

    @Test
    public void turnOnHiTempAlarmAtThreashold() throws Exception {
        wayTooCold();
        assertEquals("hBCHl", hw.getState());
    } 

    @Test
    public void turnOnLoTempAlarmAtThreashold() throws Exception {
        wayTooCold();
        assertEquals("HBchL", hw.getState());
    } 

除了違反不做思維轉換，我個人認為上述還有一點與某些測試觀點有悖，就是「不要在測試中寫太複雜的邏輯」，以避免還要寫測試去測試單元測試 (有夠拗口 )。

在重構單元測試的過程中，誕生了 hw.getState() 這個公用方法，顯然地在類似的測試中都會用到它，那麼它本身的邏輯就不能有誤。因此我猜測在這樣的情境下，我們可能會需要去寫一段單元測試，來確保 getState() 是正確無誤的，如此一來，測試程式碼就將會更加龐大了。