canonical

   單元測試隨著agile的流行已經家喻戶曉了，這正反映了軟件的一個本質特征：軟件是Man-Made的，而人是不可靠的。軟件出錯的高頻率必然導致控制 間隔的縮短。我最早是在編寫matlab程序的時候獨立的發現了單元測試的作用。因為matlab是弱類型的，橫縱矢量也不區分，很容易犯錯誤，我就為每 一個matlab函數編寫了測試腳本，約定了命名規范為xxx_test.m, 在測試的時候通過 can_assert來做出判斷而不是輸出變量內容進行人工檢查。 每次作了修改的時候，運行一下can_test_all.m就自動搜索測試腳本并運行一遍。 后來xp出現了， 我也第一次聽說了單元測試這回事，看來英雄所見略同吧 ^_^
   單元測試可以看作是對編譯器的補充。編譯器只能進行語法檢查（形式），而單元測試可以進行語義檢查(內容），它其實維護了程序的一個語義框架。如果單元測 試程序編寫出來了，即使一行業務實現代碼也沒編寫，我們手中也已經擁有了一筆寶貴的財富，因為程序的語義已經在某種意義下確定下來了。重構一般是在維護單 元測試不變的情況下進行的。即我們發現在維護語義不變量的情況下，系統具有相當的調整余地。
   堅持單元測試的另一個好處是它傾向于良好分離的模塊，因為高內聚低耦合的模塊才更容易進行測試。為了測試，我們會在不知不覺中在對象職責的分離上投注更多 的心力。在witrix平臺中，雖然基于EasyMock提供了mock支持，在實際中卻很少使用，因為模塊功能一般很獨立，不需要復雜的mock對象， 而對于一般的對象，eclipse有代碼生成功能，可以非常輕易的生成簡單的測試對象。
   雖然JUnit非常流行，我們的單元測試也是基于JUnit進行的，但是我們還是進行了一個簡單的封裝，將JUnit框架的特定要求與具體測試代碼剝離開來。具體的，測試類從
   test.UnitTest繼承，而不是從JUnit的TestCase繼承。使用Debug.check()來做判斷，而不是JUnit的assertEquals等。
   class MyTest extends UnitTest{
      public MyTest(String caseName){ super(caseName); }

      public void testMy(){
          MyObject my = new MyObject();
          Object value = myObject.myFunc();
          Debug.check(value.equals("aa"));
          // 可以同時提供一個出錯消息
          Debug.check(value.equals("aa"),"myFunc return invalid : "+value);
      }

      public static void main(String[] args){
        // 不需要IDE或者其他外部的支持就可以直接調用測試代碼，將會自動輸出運行時間等
        UnitTest.exec(new MyTest("testMy"));
      }
   }