雖然這樣的規劃聽起來不錯，但單元測試這件事說到底我的實務經驗還是太少，在這次的專案項目裡，才讓我真正有了較為深入的體會。

先對要測試的事情有一個概觀

其實測試一開始真的很難下手，主要是因為我們不知道我們要測些什麼東西。因此，我們需要對需要測試的東西有個概觀。

就以這次的例子來說吧，我要測試的東西就是「折價券攤提的演算法邏輯」，那它裡面重要的東西是什麼？

在跟客戶討論，我們得知折價券面額要分攤到的商品上時有一定的規則；這時我們就要先在紙上作業，用簡單的例子跟客戶確認清楚規則。

確認了方向之後，因為我之前已經測試架構準備好了，所以接下來就只要針對要測試的部份撰寫程式碼即可。但如果一開始還沒有準備好測試架構的話，這裡給大家幾個建置環境的簡易流程：

1. 在專案裡開個 tests 資料夾，這裡就是放置測試案例的地方。

2. 準備一個 init.php ，目的是用來設置 include_path 及 autoload 機制。

3. 按照 PHPUnit 官方的建議，建立一個 AllTests.php 的 Test Suite 。

註：這裡我就不列出程式碼了，讓大家自己試試看。

然後每次測試就用以下指令即可：

> phpunit AllTests.php

之後我會以「跑測試」來表示執行這個指令。

描繪程式的輪廓

接下來我們就要把整個系統的測試架構定義出來，不過這時候其實我們還沒開始寫程式，只是把流程和相關的方法先定義出來。

這裡的方法很簡單，就是先透過註解和方法介面來描述整個流程，而不是先寫細部的程式碼。

class Shop_Cart_Plugin_Coupon extends Shop_Cart_Plugin
{
    // ... 略 ...
 
    // 演算法計算後的結果
    protected $_sharedCouponData = array();
 
    // 取得演算法計算後的結果，也可供測試來驗證
    public functino getSharedCouponData() 
    {
        return $this->_sharedCouponData;
    }
 
    // 主要的執行方法
    public function doCheckout()
    {
        $this->_getCouponData(); // 取得
        $this->_getProductData(); // 取得商品資料
        $this->_initData(); // 初始化要攤提的資料
        $this->_shareCouponToProduct(); // 開始攤提
    }
 
    // ... 略 ...
}

當然這些都是大概的輪廓，因為可能在我們寫好測試執行時，會再額外加入新的方法及介面。

還有一個要先定義好的是測試用的比對數據格式，它對我們稍後要測試的程式寫法會有影響。

寫第一個測試

到這裡，我們就可以開始寫第一個測試，而接下來的程式碼，都是先以這個測試可以成功為目的。而這個測試要怎麼寫呢？就是把一開始我們在紙上作業的數字拿進來套用。

當然這裡我的 setUp 和 tearDown 也已經在之前準備測試架構時寫好了，它們會讓我們每次的測試數據都能夠獨立。我們關心的就是第一個測試案例：

<?php
class Shop_Cart_Plugin_CouponTest extends PHPUnit_Framework_TestCase
{
    // ... 略 ...
 
    public function setUp()
    {
        // ... 略 ...
    }
 
    public function tearDown()
    {
        // ... 略 ...
    }
 
    public function testDoCheckout()
    {
        $this->_plugin->setValue(array(
           1 => 1, // C1, ProductCoupon for P1, $100
           2 => 2, // C2, ProductCoupon for P1, P2, $100
        ));
        $this->_cart->addItems(array(
            'P1' => 1, // $200
            'P2' => 1, // $300
        ))->refresh();
        $this->assertEquals(300, $this->_cart->getTotal());
        $this->_plugin->doCheckout();
        $resultDataList = $this->_plugin->getSelectedOrderCouponDataList();
 
        $this->assertEquals(-100, $resultDataList['P1-C1']['discountPrice']);
        $this->assertEquals(-25,  $resultDataList['P1-C2']['discountPrice']);
        $this->assertEquals(-75,  $resultDataList['P2-C2']['discountPrice']);
    }
}

這裡因為我們在上一步就定義好比對用的數據，所以測試時就是用這個輸出的數據來與我們預期的數字相比較。

接下來就先跑跑測試，看看這個 TestCase 有沒有執行錯誤的地方 (例如物件沒有正確初始化或是變數名稱誤寫等等) ；當然如果沒有出現預期值是正常的，因為我們根本還沒有寫計算公式。

繼續完成演算法

現在回到 Shop_Cart_Plugin_Coupon ，我們就要把剛剛那些只有骨頭的方法開始添血添肉，這裡就請大家自行發擇。

接著只要你覺得程式差不多了，就先跑一下測試，看看是不是符合測試的預期結果。

當你完成第一個測試時，程式的就差不多完成百分之五十啦，到這裡別忘了先把程式 commit 到版本控制系統裡。

加入新測試並修改程式

完成第一個測試時，當然不是沒事了，我們要針對不同的狀況再加入其他的測試數據。

這裡我們就可以開始考慮把第一個測試以 PHPUnit 提供的 Data Provider 改寫，讓我們不必重複過多的程式碼。

<?php
class Shop_Cart_Plugin_CouponTest extends PHPUnit_Framework_TestCase
{
    // ... 略 ...
 
    public function setUp()
    {
        // ... 略 ...
    }
 
    public function tearDown()
    {
        // ... 略 ...
    }
 
    /**
     * @dataProvider provider
     */
    public function testDoCheckout($selectedCouponIdList, $productSkuNumberList, $total, $discountDataList)
    {
        $this->_plugin->setValue($selectedCouponIdList);
        $this->_cart->addItems($productSkuNumberList)->refresh();
        $this->assertEquals($total, $this->_cart->getTotal());
        $this->_plugin->doCheckout();
        $resultDataList = $this->_plugin->getSharedCouponData();
 
        foreach ($discountDataList as $key => $value) {
        	$this->assertEquals($value, $resultDataList[$key]['discountPrice']);
        }
    }
 
 
    public function provider()
    {
        return array( // 第一個測試
            array(array(
                1 => 1, // C1, ProductCoupon for P1, $100
                2 => 2, // C2, ProductCoupon for P1, P2, $100
            ), array(
                'P1' => 1, // $200
                'P2' => 1, // $300
            ), 300, array(
                'P1-C1' => -100,
                'P1-C2' => -25,
                'P2-C2' => -75,
            )),
            array( // 第二個測試
                // ... 略 ...
            ),
            // ... 略 ...
        );
    }
}

而加入新測試之後，就可以跑跑測試，看看我們剛寫好的演算法是否正確動作？通常這時候才真正是考驗的開始。因為這時候前面寫好的程式碼可能只對第一個測試正常，接下來的測試也許就會出錯了。

所以我們就會需要修改或重構程式碼，讓後面的測試也能正常執行。當然改過的程式也要讓第一個測試正常運作，才是正確的修改。

當然演算法寫好後，就要真正上到 Web 畫面去測試。至此，你會發現你花在寫測試上的心力都有了回報，因為通常如果你已經定義好介面，而這次的修改只是改寫一個小類別的話，那麼就會發現程式會非常順利地運作了。

心得

每次寫購物車時，最麻煩的就是測試時要開啟購物車網頁，把一個一個的商品加進來，再加入不同的折價券條件...

而有單元測試之後，我就可以省去一大堆開啟網頁，點選連結的功夫，專心地撰寫計算邏輯...只能說...單元測試真的個超級便利的工具呀。

官方網站 http://filenice.com/
展示網頁 http://filenice.com/demo/

介紹

filenice是一套用php編寫的檔案瀏覽工具，作用在你本身如果有架設網站並有某個資料夾提供上傳檔案，當你想要查看這個資料夾中有哪些檔案時，filenice提供使用瀏覽器就可以查看的功能。

安裝

到官網下載檔案(http://filenice.com/demo/fileNice.zip)，下載完畢將解壓縮後的檔案放到網站伺服器上你想要瀏覽檔案的資料夾下即可。

優點

官方的說明是filenice是使用php+javascript也就是所謂的Ajax技術編寫的，因此速度比較快，而且當應用程式忙碌時可以返回而不會整個畫面當掉。此外使用filenice不需要安裝任何資料庫。

感想

filenice提供了無須安裝其他軟體，僅需使用瀏覽器就可觀看主機上提供upload的資料夾下的內容，也可自訂瀏覽檔案的一些排列等細節，另外也提供搜尋的功能。不過個人比較覺得可惜的是，因為無須登入帳密即可觀看，在安全性上稍顯不足，不過或是也因此除了觀看以外，並沒有額外提供刪除或是上傳的功能吧!?介紹給大家用看看!

For Example:
Google Apps 就是用這個方式去作驗證

CNAME 是 DOMAIN or SUB DOMAIN 指向另一個 DOMAIN 的方式. (跟 alias 一樣)

那麼如果要用 PHP 實作呢? 有兩種方式 :
1. PHP5 內建的 dns_get_record() (Windows & BSD & Mac 不適用)
2. PEAR NET_DNS

NET_DNS 原理是用 fsockopen("你的 DNS SERVER IP", 53),
但是要先自己組合出 "封包的header data" 再丟過去, DNS Server 才會理你唷.
這些複雜的部份 NET_DNS 已經都幫我們做好了.

我們只要:

require_once('Net/DNS.php');
$ndr = new Net_DNS_Resolver();
$answer = $ndr->search("www.OOO.com", "CNAME");
echo "<pre>";
print_r($answer);
 
// 獲得的結果
Array
(
    [0] => Net_DNS_RR_CNAME Object
        (
            [name] => www.OOO.co.nz
            [type] => CNAME
            [class] => IN
            [ttl] => 86400
            [rdlength] => 18
            [rdata] => store	XXX�3
            [cname] => store.XXX.com
        )
 
)

PS, 在 Windows 環境, 請修改 PEAR/NET/DNS/Resolver.php 裡的

var $resolv_conf = '/etc/resolv.conf';

改成

var $resolv_conf = 'D:\Appserv\resolv.conf';

resolv.conf 要加入你的 DNS Server (請用 ipconfig /all 查詢)

nameserver 168.95.192.1

我的 Encode 規則/步驟 草稿:

1. 濾掉所有不合法的字元,  字串長度若不等於4:  error
2. 把4個字元分別轉成 ASCII code
3. 轉成ASCII code 之後 再檢查要在這個範圍以內: 48-57, 65-90, 97-122
4. 生成檢查碼(第17碼), 規則為四組數字轉為十位元數字相加總和 的 random 其中一個數字. 規則為四組數字轉為十位元數相加總和的最後一個數字
5. 自訂一個 Binary Key, 增加公式的複雜性
6. 將四組數字 "分別"跟 Binary Key 作 XOR 比較
7. 出來的結果 轉成10位元數以後再*檢查碼

範例:

Step1: ABCD
Step 2, 3:  ASCII = 65 66 67 68,
Step 4: SUM: 65 + 66 + 67 + 68 = 266,  Random 從中選一個數字: 6. 最後一個數字:6
Step 5: 自訂 Binary Key: 1010001
Step 6: 1000001 XOR 1010001 = 0010000, 1000010 XOR 1010001 = 0010011, 1000011 XOR 1010001 = 0010010, 1000100 XOR 1010001 = 0010101
Step 7: 0010000 = 16, 19, 18, 21  = [0096] [0114] [0108] [0126] [6]

寫完以上推論並人工算完第一個範例, 確定可行之後開始寫 PHPunit 的 測試程式.

過程中產生了一點疑問:

1. 若我的 output 會變 (因為檢查碼是活的, random 產生的, 也反推的回來), 那麼 PHPUnit 是否有法處理無唯一解的狀況咧??

還請 Jace 指點迷津

整個程式的思考概念是從 Andrew 提供的靈感開始：「將 4 個字元的字串分拆為字元，再由單個字元轉換為 4 個數字；最後第 17 個數字則為前 16 個數字的驗證碼」（感謝 Andrew 的分享^^）；不過準備開始的時候發現，測試的部分不知道要如何下手：「測試時，利用 function 編碼後的字串 = function 編碼後的字串？既然用到同一個 function 不是永遠相等嗎？」，所以問了一下 Jace 的用意。才發現我從 function 開始的思考方式就是錯誤的，以「測試先行」的概念來看，應該要先決定編碼過後呈現的字串，反推 function 撰寫的公式！

可是令我感到困惑的是，既然 function 就是編碼的公式；那「利用 function 編碼後的字串 = 利用公式編碼後的字串」，這還是永遠的等式啊！？我整個呈現鬼打牆的狀態！（暈）「測試先行」的概念可能是著重在思考邏輯的步驟上吧。原本的思考方式是：想 function -> 測試需求 -> 通過測試 -> 完成；但是測試先行的思考方式是：預測結果 -> 推導 function -> 測試需求 -> 通過測試 -> 完成。怎麼看都是後者比較花時間！（囧）

原本對數學就苦手的我，對於推導公式的過程是完全的頭大啊！（囧）因為昨天跟 Jace 討論的時候有提到查表法，好像並沒有限制這個方法；索性我就把 XXTEA 的公式做成密碼表，根據這個密碼表進行編碼解碼的動作囉～這次的作業還不僅是練習測試先行的概念，同時帶有專案管理的概念，要把 Jace 模擬為客戶，並向他提出需求上沒有的問題；是老師的用心良苦，也是學生的額外課題（囧）！

對我來說測試先行的優點在於，思考的邏輯更為清晰；就好像畫素描一樣，必須先從大輪廓開始，在一步步修飾細部才能唯妙唯肖。缺點是必須經過比較多步驟，可能會增加許多不必要的時間。畢竟當畫素描是一個有限定時間的考試時，雖然慢工出細活，但能不能拿到高分就難說了～^^|||

測試先行作業 PART2 下載（090804修正程式）

周末假日前的午後，
我們再次相聚於果子咖啡。

大夥仍舊是人手一台notebook，
果然是資訊人的標準配備。
就像安全氣囊之於車子一樣...

小鐵老師神來一筆的幽默，
讓原本生硬的主題多了一分輕鬆感。

這次的上課人數較上回多了點，
在果子的幫忙下做了最佳的位置排列，感謝果子~
也感謝大家的包涵^^

認真的男人最帥氣~
(這兩位朋友上回也有來捧場喔!)

課程中帶入時事，
Dell 事件帶給大家的警惕與學習。
測試是必須的，也很重要...

大家熱烈討論中，
謝謝各路高手的鼎力相助!
(上圖左這位大哥也教了我們很多呢~鞠~~)
上課最珍貴的地方除了可以學到老師的專業，
另外就是大夥的相互討論與分享~

這次又認識了一些新朋友，
無論是第一次或再次參與哇寶的課程，
希望本課程對大家都能有所幫助喔~
若對於課程有任何心得或建議，
也歡迎大家與我們分享。

期待下一次再與你相聚~^^

*課程簡報：

[附註]
大澤木小鐵老師的e-mail : jaceju@wabow.com
大家有任何程式技術上的疑難雜症，
歡迎來信與小鐵老師討論喔~!

總共花的時間(去除掉安裝 PHPUnit), 大概是 2小時又多一點吧

我感受到使用 PHPUnit 的優點

寫到第九, 第十個條件的時候, 我發現我可以一次測全部十個, 這樣一次到位的感覺還不錯. 在過去我的作法就是一個一個試, 跟 "憑經驗" 囉.

因為寫程式常常會發生: 新增了OOO, 舊的XXX壞了, 只好再重修, 再測試... 有時隔段時間再寫, 遇到這樣的狀況真的還滿頭痛的.

我想等到假如有100條件的時候, 測試先行這個優勢會更明顯.
另外, 我有兩個問題想問 Jace 的是:

• 第8, 9 一定要用 TDD 的用意是?
• 還有結果我沒有用到 testBuildImage() 跟 testBuildYoutube() 耶 ..... 那我要怎麼用它們呢?

心得

1. 單元測試 我想可能就像"條列"可以幫助思考一樣吧, 把一個很複雜的東西打散成很多個小部份, 等到全部的小部份完成, 再組合起來即是(接近)完成, 簡單明瞭. 以提升人類處理事件的效能來看, 可能會真的會比較快也不一定喔!?
2. 第二個我覺得會比較快一些的理由:  當我們單純地只去做某一部份, 以 performance 來說, 如果每次 reload 都快個 2 秒, 那100次就快200秒囉.
或許在這一次的作業, 我們感受不出來很大的差別, 但假如 我們在一個已存在且龐大的 framwork 架構下寫程式, 而每一次 reload 都要連資料庫, 跑 3-5個 sql, 然後才去執行程式, 長期下來就會慢滿多囉.

例如：在試著轉換輸入字串時，網頁上看到的樣式是
Yahoo
看起來是對了，but.....！實際上是錯，因為轉換出來的其實是

<a href="http://Yahoo">Yahoo</a><a href=""></a>

為什麼輸出字串會發生錯誤呢？因為我程式寫錯了 (廢話)
重點是，網頁上瀏覽的結果是"對的"，實際上卻是錯的，當透過PHPUnit檢測，就能正確的顯示錯誤

所以目前的感受，是PHPUnit在Html檢測上比較實用？！as 阿丹`s talk (誠如阿丹所言) (請suzy小老師幫看文法是否有誤)，我應該也沒那個View....尚不得其單元奧義 囧

參考這個網站來安裝卻一直發生找不到相關路徑的錯誤，就算手動指定也是一樣。後來回家後改在自家電腦安裝，先參考這篇安裝完 PHP5 開發環境，然後成功安裝PEAR，最後成功把phpunit也安裝完成。
簡單註記一下用PEAR安裝phpunit的指令如下︰

pear channel-discover pear.phpunit.de
pear install -a phpunit/PHPUnit

實際使用phpunit來實做TDD(Test-Driven Development)，以網址自動解析功能來說，如果不使用單元測試的情況下話，要測試單一function在執行上是否有問題，必須要先作一個簡單的輸入框頁面，然後針對此頁面編寫針對輸入值作後續處理的code，然後構思各種輸入值的可能來測試function是否有誤，然後在逐步去修改function中邏輯。如果是使用單元測試的話，可以不用製作輸入框的頁面來測試，只需要依照格式編寫測試程式，再透過provider的模式將要測試的資料透過陣列方式逐一填入後再逐項測試。

我覺得透過單元測試的作法對於function的測試上比較有一個依循的規則，同時也可以紀錄在測試這個function時有用哪些資料型態測試過無誤，對隔了很長時間後如果有追加功能時有比較清楚這個function當初有做了哪些資料的測試以方便編寫追加功能時的參考依據。因此我覺得單元測試的確有其幫助程式編寫上邏輯釐清及確保功能無誤的作用，不過如果案子規模較小且時程上比較趕的時候，還是要斟酌是否要執行單元測試，這在實務上的確還是有需要考量的地方。

課題作業的內容，是仿造知名微網誌噗浪的訊息輸入，在輸入符合某些 Url 規則時，自動轉換為 HTML 語言。當然當我們需要判斷某些特殊規則的時候，非常直覺的一定會想到大家的好朋友「正規式」！但也因為正規式的出現，有點模糊了原本體驗「測試先行」的目的，大部分寫作業的時間都耗在正規式的判斷與寫法...正規式是程式語言界中的火星文啊！（吼）Wiki 其實已經提供很好的正規式說明，不過「正則表達式30分鐘入門教程」提供更完整詳細的說明，尤其是「後向引用」更是以前想都想不到的使用方式！「Regular Expression Library」提供很多網路前輩們已經寫好的正規式判斷，算是非常完整的正規式資料庫唷！

因為其實我還是用傳統的 Redo & Debug 的方式，所以對測試先行並沒有特別的感覺，反而是採用「測試最後行」（有這種說法嗎？）的方式（因為最後幾題 Jace 指定要用單元測試的方式...），把 function 都寫好以後才開始寫測試程式；不過在全部測試時，Provider 提供的批次測試的確有比程式寫死或是一般網頁輸入要來的方便許多。算是有贏傳統開發模式的地方吧～但是我還是覺得使用測試先行應該會比較花費時間耶...（囧）果然這種嚴謹的開發模式，不是我這種目光短淺的人所能了解的吧！（沒有 View，噗）

測試先行作業下載

一個網站的完成，從初期與客戶詢問需求、撰寫相關文件，到中期的版面設計及程式撰寫，到後期網站測試、驗收文件撰寫，最後專案結案及後續維護，是一個很長的生命週期。每個環節的執行是否完善，都深深影響到最後網站專案是否如期完成。那個到底何謂單元測試呢？其實就是一種程式面的測試。說到網站測試大部分直覺想到的就是依照當初開的需求文件逐項操作網站各項功能，然後一一把有問題的部份條列下來，在交給相關部門作修改，這就是一般所謂QA部門每天所做的工作。等到相關部門逐項處理完畢後就再次回報給QA，也就是作複審的動作，如果沒新發現的問題就表示內部測試完畢，可以通知客戶開始測試了。那麼單元測試跟一般的測試有何不同，讓我們來看看。

何謂單元測試

單元測試的單元，是程式中不可再分割的單元，通常是函數或類別的方法。最基本的進行方式是傳參數給函數/方法，然後檢查他的反應是否正確。其特別之處是在網站開始動工前執行的動作，也就是先行測試開發的概念。當整個網站程式尚未開始編寫前，先規劃出要測試的功能部份有哪些，如果都測試無誤才開始著手網站的程式編寫。或許有人會問，為何不等網站程式全部編寫完畢後再來作測試？其實單元測試就像是網站整體架構及流程的預覽動作，把要測的項目先釐清出來，如此之後再開始著手編寫程式時就不至於偏離網站需求太遠，這就是單元測試的魅力。

單元測試的工具

常見的工具如JUnit(http://www.junit.org/)或是PHPUNIT(http://www.phpunit.de/)，都是很常見的，端看你的開發環境是用哪一套。如果想學習JUnit的用法可參考JUnit 學習筆記(http://caterpillar.onlyfun.net/Gossip/JUnit/JUnitGossip.htm)；如果想學習PHPUNIT可以按此報名於7月24日哇寶資訊技術總監JACE所開辦的PHPUnit 入門講座，人數有限，盡早報名。

一些參考網站

單元測試解析 http://jyhshin.pixnet.net/blog/post/28084838

單元測試及先行測試開發 http://www.microsoft.com/taiwan/msdn/library/2003/apr-2003/csharp03202003.htm

使用單元測試 http://msdn.microsoft.com/zh-tw/library/ms182515(VS.80).aspx

在茫茫網海收集資料的過程中，又發現到「Continuous Integration」這個軟體開發時的一種專案管理方式，它也十分重視測試的重要性；同時整合統一的版本控管系統、以及配合開發人員的撰寫精巧易維護，低耦合性的程式碼、最後經由一定時間自動從版本控管系統把程式拉出來測試，自動 build，自動通知相關人員的全自動化處理，做最完善的軟體專案流程控管。聽起來感覺上是非常理想又完美的軟體開發方式！（夢幻？）

太過深入研究軟體開發，似乎會有一種沒完沒了的感覺...（囧）單純就「單元測試」來說，是對於程式最小單位的類別，針對其內部邏輯正確性的驗證；所以通常一個程式類別，就應該伴隨著一個針對該類別，檢驗其內部方法的測試類別。因為單元測試的特色：徹底性、可重複性、獨立性與專業性，讓需要經由大量資料測試的程式，透過單元測試的方式達到自動化，並有效減少正式上線後錯誤的發生，達到令程式變得更加完美的目的。

然而現實環境通常沒有辦法盡如人意，撰寫單元測試就意味著必須花費額外的工時，在一秒鐘幾十萬上下的台灣似乎是一件不可能的任務；更不用提那夢幻的軟體開發方式 Continuous Integration 了...這樣的現實狀況似乎有呼應到教育訓練結尾的結論：「小案子就放它一馬吧；對 Web 開發而言，一般的 CRUD 並沒有特別需要作測試」。

不過隨著網際網路的發達，Web 的開發好像也愈來愈複雜；在 Google 都放出 Google Operating System 的現在，愈來愈有一種「網路是充滿無限可能，實現夢想（我要成為網路王？）的最佳舞台」的感覺！或許在不久的將來，程式的困難度與複雜度，讓測試變的更加困難時，單元測試的導入會是很好的解決方案...吧？

P.S 另外對於教育訓練中提到的「測試先行開發模式」，我深深的感到困惑；如果說在開始撰寫程式碼前必須先寫測試，那單元測試中需要引入的類別要從何而來啊？不先寫程式類別，要怎麼做 Test case 呢？

參考資料：

• Midnight Blog Continuous Integration
• 當紅炸子雞 Continuous Integration
• SuiFei 單元測試基礎知識

不過另一個角度來看，Unit Test可以當作"範例"，測試過程其實也就是說明程式是如何運作，可以讓其他人容易瞭解你的流程，另外就是遇到一些重複性很高的測試等等。

不過可能是還沒親身搭配專案使用過，目前對於Unit Test實用性還是一知半解，看不到他深處的美好，就像尚未接觸樣板概念前，完全不瞭解他的實用度，直到實際試用過後，才能深深瞭解重要，不過依照目前接觸專案的等級，好像還用不到Unit Test，有機會 .... 再來用看看吧，因為 『小案子就放它一馬吧』！！！！

Testing 的定義

大學時有學了一點皮毛, 大概知道 什麼叫 White-box testing 跟 Black-box testing

• White-box testing 通常是以程式師的角度, 在懂得程式架構下的測試
• Black-box testing 通常是以使用者的角度, 在不知道葫蘆裡裝什麼藥的情況下的測試

這裡還有好多好多種的測試定義唷:

• Software testing
• Hardware testing

與 Web Development 有關的:

• Sandbox testing 就像我們的測試機.
• Web testing 是在指測試大流量下才會出現的bug 及 硬體效能問題
• Ad hoc testing 無章法亂測, 也是一種測法!!
• Usability testing 可用性測試 - 要考慮 Performance(效能), Accuracy(準確), Recall(回傳), Emotional response(情緒反應) .. 我記得以前學校有一門課叫 Human-computer Interaction 就是在講這個, 也是 Fail 很多人的一門課 因為很難 哈哈哈哈
• Localization testing 在地化測試

Unit testing 存在的目的

提昇程式穩定度，帶著更清晰的腦袋瓜寫程式

那麼 Unit testing - 我想把它解讀成它是一種寫 testing 的方法/模式

而 Test-driven development 就是先寫測試 再寫程式 的一種 Software Design Mode?

TDD 標榜的是先寫好測試的 cases 再開始寫程式. 寫 code 時就比較不會造成程式的漏洞.

我想到一句對我還滿受用的一段至理名言:

能夠迅速想到解法的程式設計師太多了。
他們能用一分鐘想到方法，用一天去寫程式。
不需要花一小時想到解法，再用一小時去寫程式。
- Jon Bentley

TDD 某種程度上應該也是這個意思吧! -- 多花點時間準備 before writing.

而有 Unit testing 就有 Integration testing 整合測試 -
Unit testing --> Integration testing --> System testing (Black-box)

Unit testing 實際應用(我目前想得到的)

其實就是一些很容易算錯的東西..........

• 匯率
• 運費計算
• 所有功能都寫在一起的購物車
• 商業應用..eg 租露營車的估價, 牛的乳腺炎線上計算(我真的做過! 超難寫的! 這個超需要 Unit testing, 還有 Integration testing !!!)

Unit testing 很難達到實際功效的困難點

1. 程式師本身的盲點, 搞不好寫了測試但是 bug 還是在 *_*
2. 客戶會改變需求, 有沒有寫了又改, 改了又寫的八卦

我又想到一段至理名言:
需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。

3. 與時間賽跑, 有時間寫再說
4. 測不到的地方 - 視覺沒有辦法測，調 css 排版沒有辦法測，Ajax 操作也很難完全模仿人的習慣，還有 BROWSER 的問題。

結論

Testing 其實很複雜, 應該也只有巨大案子才需要吧.
真的要做的話, 應該還包括各種 case 的分析, 連鎖反應, 如何將各種 testing 運用得宜, 還有流程控制, 可能要畫一堆的 UML Diagram, 還有預演替代方案
應該不是三言兩語就可以說得完的 @o@
而我們的 Web 開發所需要牽涉到的 testing 技術可以到什麼程度其實我也不知道

其實這篇淺薄的心得自己寫得很不好意思, 因為沒有接觸很多, 請大家隨便看看ㄚ, 真的要循續漸進且觀念正確地瞭解透徹, 我覺得可能還是要向學術界取經吧 ^^" (逃)

課程主題：PHPUnit 入門

身為一個工程師的你一直把時間花在 Debug 嗎？
為什麼就不能有一個值得信賴的方式，幫助我們驗證我們的程式碼是正確的呢？
當然有！那就是單元測試！！

一般人在用 PHP 開發 Web 時，一直很少注意到單元測試這件事，
現在，該是大家去瞭解它的時候了！

來吧！一切就在 PHPUnit 裡，等著你們來發掘~

上什麼？
      一、單元測試是什麼？
      二、單元測試的相關概念
      三、PHPUnit 基礎特色介紹
      四、問與答
      (註：時間來得及的話，會讓大家一起練習 TDD 開發)

誰來上？
     朱建志 (Jace Ju)
     職稱：哇寶國際資訊技術總監
     外號：大澤木小鐵
     興趣：分享技術研究心得

適合誰？
     - 對 PHP 開發已有兩年以上經驗。
     - 對物件導向有基本認知。
     - 對程式碼自我要求甚高。
     - 對學習新技術有興趣。

何時上？
     98 年 7 月 24 日(五)  PM2：30 ~ PM4：30

在哪裡？
     GozCafe 果子咖啡
     地址：台北市民生東路三段 140 巷 11 號
                (捷運南京東路站下，直走慶城街，左轉興安街)
     電話：02-8770-533

課程費用？
      不需課程費用，但需自行負擔果子咖啡午茶低消費用 100 元。
      午茶內容：精緻午茶茶點(飲料限點 100 元以下) + 一份果子每日茶點
                         (也可依個人喜好自行選擇其他餐點，價格依餐點內容而定)
      ※ 備註：入場前請先至櫃檯點餐結帳，謝謝！※

人數限制？
      本次課程力求溫馨與實用走向，上課人數限 20 人以內，
      有興趣的人請及早報名，以免向隅喔！

報名方式？
      有興趣的朋友麻煩請至~ http://registrano.com/events/phpunit-basic 進行報名！

主辦單位：
      哇寶國際資訊股份有限公司