哇寶部落格 » 單元測試

[心得] 測試先行作業與相關心得 PART2

daniel — Thu, 30 Jul 2009 03:14:56 +0000

經過上次歡樂（？）的偽噗浪網址轉換器後，本週的作業是「編碼解碼器」；完全沒有測試先行概念的我，首先當然就專注在編碼解碼資源的搜尋上囉！拜 Google 大神後發現也不少推薦的可逆的加密演算法：知名的 AES、3DES，雖然網路上提供許多詳細又完整的 PHP 實踐方式，但是跟此次作業要求的「最後呈現的方式必須為數字」的條件不符。後來稍微看了一下之前在專案中曾經使用過的 XXTEA，發現裡面就提供數字轉字串，與字串轉數字的函數；真是太棒了！

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

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

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

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

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

[心得] 測試先行作業與相關心得

daniel — Thu, 23 Jul 2009 02:40:19 +0000

「測試先行開發模式」其實在上週的《[心得] 單元測試相關心得：單元測試與軟體開發》就已經提到，Wiki 也把它相關的正反面評價也寫的很清楚；本週的課題作業就是要試著以這樣的模式進行開發。不過因為我跟阿布覺得「測試先行」這個概念實在很弔詭，所以非常幸運的還是使用原始的開發模式。最後由 Suzy 做實驗組，我們為對照組的方式；實際比較二種開發模式的不同。

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

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

測試先行作業下載

[心得] 單元測試相關心得：單元測試與軟體開發

daniel — Thu, 16 Jul 2009 06:33:09 +0000

上週經過 Jace 介紹 PHPUnit 的教育訓練，稍微了解關於 PHP 在單元測試時，使用 PHPUnit 應該如何運用。雖然開場的時候有簡單解釋一下什麼是「單元測試」，但是因為小弟在下資質駑鈍，完全處於一種有聽沒有懂的狀態；所以後來 Wiki 了一下，才知道單元測試僅是複雜的軟體測試的一小部分，而軟體測試，又只是龐大的軟體開發中的一個環節而已！（暈）

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

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

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

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

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

參考資料：