哇寶部落格 » PHPUnit

[心得] 用 PHPUnit 開發體驗II

suzy — Fri, 31 Jul 2009 04:12:57 +0000

這次利用 PHPUnit 開發編碼解碼器... 體驗一下... 我需要 Fu ~~~~

大致的開發過程應該跟大家都差不多, 有為了是否要再細分更多的小 assert function 猶豫了一下, 不過最後還是統統寫在一起.

我的 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 指點迷津

[心得] 用 PHPUnit 開發初體驗

suzy — Thu, 23 Jul 2009 06:26:34 +0000

PHPUnit = 在黑黑的 console 下寫程式

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

我感受到使用 PHPUnit 的優點

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

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

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

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

心得

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

[心得] 測試先行感想 Part One

abu — Thu, 23 Jul 2009 06:01:07 +0000

恩，這次的題目『仿噗浪之輸出字串替換』，感覺比較有趣部份，就是替換過程，為了讓流程簡化當然正規式是不二人選，如同阿丹提到的，這是場與正規式的拉力戰，戰勝正規式的就能戰勝噗浪(是這樣說的嗎？)，一方面使用PHPUnit提供的檢測方式，一方面使用傳統的Reload大法檢測，說真的，感覺不出來差別，真的要說就是，一邊是全彩FullHD這樣，畫面很漂亮，瀏覽器五顏六色這樣，一邊是Dos畫面，跟Mud一樣，會出現偶發的Perform(施展外功)帶出來的彩色文字，看到都是綠字的時候代表對方被你打死了或是中毒很深代表檢測通過了，目前有感受到一個好處，就是『看到是對的，不一定是對的』↓

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

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

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

所以目前的感受，是PHPUnit在Html檢測上比較實用？！as 阿丹`s talk (誠如阿丹所言) (請suzy小老師幫看文法是否有誤)，我應該也沒那個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 呢？

參考資料：