在日常使用的Test Framework所產出的Test Report並不是標準的 JUnit 格式。所以這使得想要回傳Test Result到Jenkins的時侯，沒辦法把 Test Result 顯示在Jenkins的Build的結果上面。然而產生JUnit report的功能在一般的Test Framework像是nose跟py.test都有，像是nose就有一個plugins是專門在處理這個問題，或者是py.test可以直接使用py.test --junitxml=path來產生。可惜我的工具沒有。所以只好自己弄一個了。在此記錄要如何完成這個任務。

上網 Google了一下有關JUnit XML format到底長怎樣，找到Stackoverflow這篇有討論，基本上可以解決90%的疑問。有關XML的定義可以從.xsd檔中找到，而JUnit的.xsd檔，這邊可以下載。我使用XMLPad來打開，再掛載xsd的schema檔，手動體驗一下 xml 的format，基本上最簡單的的JUnit Report大概是這樣：

<testsuites xsi:noNamespaceSchemaLocation="file:///D:/junit-4.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<testsuite name="INSTALLATION RAT">
    <testcase classname="INS_RAT_0001" name="Test Case Title Sample 1" time="0.046">
      <system-out></system-out>
    </testcase>
    <testcase classname="INS_RAT_0002" name="Test Case Title Sample 2" time="4.868">
        <failure message="case failed …

測試的重點

軟體測試在敏捷化開發一定會遇到的問題，就是原本很可能都是以“週”為單位完成的Task。如果在一個三週Sprint的情況下，測試工作很可能都要變成以“天“為單位完成的Task，我們要如何能把大部份的測試活動都在短的時間區間完成！？如同 Scrum 大師 Mike Cohn 所說的，我們需要一個健康測試金字塔。把時間投資在對的測試活動上。

金字塔有三層，由下而上分別是 Unit Test ，Acceptance Test, GUI Tests。最上面不一定大小的 Manual Tests。這邊傳達的最重要的概念就是，我們應該盡可能地把時間投資在 Unit test 上，理由很簡單，因為 Unit Test 穩定度是最高的，而且最容易被執行。如果一個測試目標能在 Unit tests level 被處理掉的話，我們應該要盡量讓它們在 Unit test level 就發生。而當測試的 Scope 愈來愈大，測試的成本就會愈來愈貴，可能會由白箱測試變黑箱測試，所需要的測試文件就需要更多來傳達資訊。

很可惜地，大部份的測試團隊，剛好相反。投入了大量人力在 Manual tests 之上。也因為有大量的 Tester 在執行 GUI Test、Manual Test 所以 Developer 在相對少的資源下，就只能把大部份可以在 unit test level 就處理掉的任務直接讓給 tester 來完成。

金字塔 與 三隻小豬的故事

Patrick Wilson-Welsh 把這個金字塔比喻成三隻小豬的故事。有做過 GUI test 的人應該都知道，我們應該最後才做 GUI test，因為他最 brittle，最容易因為一點點的改變而讓測試不通過。所以 Patrick …