WadeHuang的學習迷航記

我的團隊在開發階段中，習慣以 rsync 將本機上的程式碼同步至 測試機 上運行。 因此替功能撰寫測試案例後，必須經過一些設定才能 遠端執行測試案例 。 以下將提供 PHPStorm 遠端執行測試案例 配置步驟，

本篇文章紀錄自己導入 測試驅動開發（Test Driven Design） 過程中，曾經沒辦法分辨自己所寫的測試案例到底是“單元測試”還是“整合測試”，與同儕討論後發現其他人也有相同的困擾，於是看了幾本書與文章才釐清自己的問題所在。為方便與其他人進行交流討論，故將自己理解的資訊整理下來並做個總結。 單元測試的涵蓋範圍很模糊？ 單元測試（Unit Test）是軟體開發中很重要的環節，替 TDD 提供重構的保護網，也是軟體測試（Software Testing）中測試金字塔（Test Pyramid）的最低測試層級。 但是，一個「單元測試」所涵蓋的範圍到底有哪些，卻讓國外網友議論紛！ 大家在初學單元測試一定會看到的定義如下： 以程式碼的最小單位來進行正確性檢驗的測試工作，最小單位包括「類別與方法」。 若按此定義來寫測試案例，一個單元測試只能包含一個類別。且受測類別的依賴都必須透過測試替身或 Mock 技術進行隔離，才能確保測試的目標是最小且不可分割的邏輯。 但是隨著 Mock 的詬病被發掘（參考： Mock 不是測試的銀彈 ），為避免 Mock 使測試案例變成開發人員的快樂表（測試通過，正式環境卻出現錯誤），開始有人提倡使用 Spy 來替代 Mock，以及依賴若是自己的開發團隊所寫，而非第三方函式庫，則可直接使用依賴。 這時，一個單元測試會執行的範圍已經從 一個類別 變成 一個類別加上該類別的依賴 。換句話說，一個單元測試除了受測程式外，也會執行到其他類別的程式碼： describe( 'AddGroupToRange' , function () { it( '空的統計範圍, 將題組「questionGroups1」新增至空的統計範圍中, 統計範圍包含題組「questionGroups1」' , function () { // @given 空的統計範圍 var range = new StatisticsRange(); var pipeline = new Pipeline(range); // @when 將題組「questionGroups1」新增至空的統計範圍中 pipe

本文將帶領讀者建立 CodeIgniter 3 框架的 PHPUnit 測試環境，給 CodeIgniter 3 一個現代化的機會！ 本文假設您已經具備 軟體測試自動化 以及 PHPUnit 相關知識，且了解如何撰寫測試案例。若您尚未了解單元測試或軟體測試自動化，這裡提供一些不錯的資源讓您初步了解： otischou.tw：瞭解單元測試 阿川先生：先寫單元測試的12個好處！ 除了上面兩個資源外，請您務必花時間認識並學習軟體測試，這可以說是軟體開發技術的核心技能之一。 若您尚未了解 PHPUnit 這裡也有些簡單的文件供您參考： PHPUnit 官方中文文件 Jace Ju：PHPUnit 入門介紹 前言 2020 年對於 PHP 界風靡一時的 MVC 框架「CodeIgniter」來說，光環已經被新星 Laravel 搶去。雖然 CodeIgniter 的討論熱度已經消退了，但市佔率仍然相當高，至今仍有許多 PHPer 還在與 CodeIgniter 奮鬥和成長（包括我）。 由於 CodeIgniter 3 框架（以下簡稱 CI3）沒有使用 Namespace 的特性，加上 CI3 統一透過框架內建的 Loader 類別實現 Autoload 機制，造成很多 PHPer 沒辦法在 CI3 框架中使用現代 PHP 的特性來開發系統。若不做點手腳的話，PHPer 的開發思維很容易就會被 CI3 框架綁架，一不小心就將所有業務邏輯全部寫在 CI3 框架中。換句話說所有的程式碼都依賴於框架，物件導向 SOLID 原則的實現、設計模式、單元測試 …等較進階的管理程式碼策略都不用談了！ 為了讓還在與 CI3 奮鬥的同袍們能夠使用現代 PHP 的特性來開發系統，本文將介紹如何在 CI3 框架中建立單元測試的環境，讓 CI3 也能使用並測試現代 PHP 的程式碼，確保 PHPer 能安心地實現各種開發策略和思維。 導入 Composer 擁抱現代 PHP 特性 其實 CI3 跟現代 PHP 只差臨門一腳，你可以在 config/Config.php 中找到一個設定為 composer_autoload ，只要替 composer_autoload 設定 Composer 目錄底下的 autoload.php 路徑，你的

The Art of Unit Testing: with examples in C#, 2/e 書本連結 摘要： 本書涵蓋了撰寫單元測試的基本知識，包含如何撰寫單元測試、使用隔離（模擬）框架，以及讓它們變得可維護、可讀、可被信任。並且講解在真實世界撰寫、管理和維護單元測試的最佳實踐。 心得： 第一、二章： 作者示範一個良好的單元測試應該具備哪些條件。 第三、四章： 作者以設計單元測試的角度，引用 Working Effectively with Legacy Code 的接縫技術講解如何透過接縫技術建立偽物件，讓單元測試的受測對象(SUT)可以隔離依賴，達到快速、獨立原則。 接縫技術是針對 Legacy Code 無法執行單元測試的處理手段 ，由本書的角度來學習接縫技術，會覺得為什麼要繞一大圈只為了產生偽物件(Stub/Mock)。因此建議直接去看 Working Effectively with Legacy Code 如何使用接縫技術讓多種情境的 Legacy Code 可執行單元測試。 第五章： 使用模擬(Mock)框架來取代三、四章節的接縫技術。 覺得此章節的安排不太洽當， 接縫技術是針對 Legacy Code 無法執行單元測試的處理手段 ，作者卻以取代接縫技術的角度來介紹模擬框架，可能讓讀者誤以為接縫技術是過時的測試手段。 也許是本書出版的年代較早 (1/e: 2009、2/e: 2013)，但現今的測試框架搭配模擬框架已經相當普及。若要講解模擬技術時，應該直接講解模擬框架即可，把接縫技術跟模擬技術分開講應該會更好！。 第七、八、九、十、十一章節： 介紹開發團隊在實務中如何進行單元測試，包含如何安排單元測試的檔案、舊系統引入單元測試的策略、如何讓單元測試好維護..等等。 若您的團隊還不了解怎麼進行單元測試，則相當推薦閱讀這些章節。 總結： 本書的深度不深，作者把讀者設定為單元測試的新手，從 0 開始講解單元測試，書中的內容大多是針對不良測試案例的叮嚀。 推薦給想學習單元測試又對單元測試不了解的工程師，本書將單元測試應該具備的概念都教完了，讀過後應該能少走不少歪路。 適合讀者：對單元測試不了解的工程師 可學習議題：單元測試技術 延伸學習：測試驅動開發（TDD)、行為

Why SQLite？In Memory 模式 SQLite 可開啟 In Memory 模式 在記憶體中操作資料庫 ，程式關閉後，記憶體內的 SQLite 資料庫也會清空，相當適合測試環境使用（無副作用）。 建置步驟： 產生假資料，先匯出 MySQL 備份檔 將 MySQL 的備份檔轉換成 SQLite 格式的備份檔。 最後再將 SQLite 備份檔配置到 CodeIgniter 的 database.php 設定檔中。 config/database.php if (ENVIRONMENT == "testing" ) { $db [ 'main' ] = [ 'dsn' => ':memory:' , // 啟動 In Memory 模式 'hostname' => '' , // 不需填寫 'username' => '' , // 不需填寫 'password' => '' , // 不需填寫 'database' => APPPATH . 'database/sqlite/sqlite.db' , // SQLite 備份檔案，絕對路徑。 'dbdriver' => 'sqlite3' , // 使用 SQLite 'dbprefix' => '' , 'pconnect

測試的術語 3.1.1 測試覆蓋率 Coverage 測試覆蓋率以百分比表示，用來測量有多少行程式碼已經被 測試程式 執行過。 如果你的程式碼有 4 行，但只有其中 3 行被測試程式執行過，那麼測試覆蓋率就會是 75%。剩下的 25% 可能是應該要廢棄的程式碼，或者是不屬於這個類別的工作責任，應該被移動至屬於他的地方。 以下列出多種測試覆蓋率的用途： 中文名稱 英文名稱 用途 函式覆蓋率 Function Coverage 確保每一個方法至少執行一次，且沒有發生錯誤。 行數覆蓋率 Line Coverage 確保程式每一行至少執行一次，且沒有發生錯誤。 決策覆蓋率 Decision Coverage 確保每個以真偽 (true/false) 控制程式走向的分支，至少被執行一次且沒有發生錯誤。 條件覆蓋率 Condition Coverage 確保每個分支是至少執行一次，並且沒有發生錯誤。 注意：為了滿足決策覆蓋率與條件覆蓋率有多個分支，必須針對每個分支的情境撰寫一個測試案例。 對測試覆蓋率的觀點： 覆蓋率數據只能代表你測試過哪些代碼，不能代表你是否測試好這些代碼。 不要過於相信覆蓋率數據。 測試人員不能盲目追求測試覆蓋率，而應該想辦法設計更多更好的案例，哪怕多設計出來的案例，對覆蓋率一點影響也沒有。 結論： 測試人員不應該為了滿足測試覆蓋率而撰寫測試案例，應該要以「使用情境」撰寫測試案例。 ​