＊＊ 本文同步發表於 FB社群-軟體設計鮮思維 ＊＊
最近在線上輔導了一位 技術職PM 結構設計的實現 (Realization)議題，他傳給我 DDD 的架構圖，覺得在「Domain Service」與「Domain Model」的責任界定上，觀念不是很清楚。
嗯，其實這所謂的 DDD (Domain Driven Development) 架構圖根本就是典型 3-tier (Presentation-Application Logic-Data Source) 分層結構呈現爲圓形的剝洋蔥層次而已，越是內層 (Domain Model) 越代表爲系統的核心。
工程師從這張圖往往會認爲「Domain Model」是最重要的核心觀念。是這樣沒錯，但對以「需求爲導向」的專案開發性質，它卻反而沒那麼重要！況且結構設計的基礎功夫要很紮實，封裝-介面-多型 諸多「虛」的設計觀念確實能充分了解並能整合活用，沒有花上 5-10 年以上功夫，是不容易應用在現實的系統開發上的。相對於此，「Domain Service」對現實的專案開發可是更切實際，且結構設計上的觀念也會比較容易入手。
＊＊ 本文同步發表於 軟體設計鮮思維FB社群 ＊＊
上星期我在教授 TDD.NET 測試驅動開發課程。其中有位學員分享他們公司會計系統的部分程式碼 (沒有機密性議題)，想知道這該如何撰寫單元測試 (Unit Test Code)。
我先用 EA (Enterprise Architect) UML 工具掃描程式碼反轉為 類別 (Class) 圖，老天！數百個 Windows Form (每一個 Form 他們稱為 Report) 全連接到一顆共用的 DB Manager，封裝了基本的 CRUD 行為，再存取資料庫。剛掃進來時還真嚇了一跳跳，那個 Form 的連線，有如積體電路般密密麻麻的共同連接到如同就是 CPU 地位的 DB Manager！
這肯定就是典型技術人員的傑作，用許多稀奇古怪的實作方式，讓所有的表單 UI 程式，傳進來 SQL 敘述，然後再去存取資料庫。看似方便簡單，但這顆萬用的 DB Manager 已經被約束了特定的實作技術與特定的資料庫，所以當然無法抽換，原來他們使用 ADO.NET 的連線，現在是不可能換成 Entity Framework；不僅如此，內部程式碼的擁腫肥大，當時的技術人員一離開，幾乎達到無法維護的地步。
最近申請到「群益報價/下單 API」，也下載了 C#.NET 的範本，但卻是用 Visual Studio 2010 編譯的專案，花了一個多小時手動編輯 .csproj，總算可以在 Visual Studio 2017 開啟執行。
不過範本寫得非常之亂，典型的全把所有邏輯寫在 Windows Form 類別。實在看不下去，準備把一些主要呼叫的 API (Login,下單,報價) 重整下，從 Windows Form 全抽離出來，並撰寫單元測試 (unit test) 方便測試。
群益API 是採以 COM 相對底層機制所撰寫的，使用前要先註冊該元件 (SKCOMLib)。我直接採用 x64 64位元的處理器架構，完全不考慮 32位元，還好群益都有提供。
程式撰寫挺簡單，但執行單元測試卻出了問題，只要將「目標平台 (target platform)」改為「x64」就會出現一些很怪的錯誤訊息。原來以為是呼叫 COM 出了問題，甚至打電話問了群益的資訊部人員，但他們竟然說沒聽過單元測試，程式沒有從 Form 開始就看不懂。挖哩，不過他們確信 COM 元件沒有問題，看來還是出在環境設定上。
查找解決文與 Try-Error 大半個下午，總算，就是只要在 Visual Studio 2017 選單「測試」→「測試設定」→「預設處理器架構」改為「X64」就 OK 啦！
＊＊ 本文同步發表於 軟體設計鮮思維FB社群 ＊＊
看到國外某作者的一篇論述：「Lean Testing or Why Unit Tests are Worse than You Think」。這篇文章我瀏覽了兩遍，思考原作者從什麼樣的角度來看待所謂的單元測試 (unit test)。
文內有提，他純粹從經濟 (economic)的觀點來看待測試，然後接著從三項因子：成本 (Cost)、速度 (Speed)、信心 (Confidence)來比較 整合測試 (integration test) 與 單元測試 (unit test)的價值。
他的結論是認為：整合測試相對來得有價值許多。🤔
然後接著他再用 投資報酬率 (ROI, Return on Investment)與 程式覆蓋率 (Code Coverage)來佐證 整合測試 的高投資率。
這就讓我更肯定了，原作者是站在專案經理人 (PM, Project Management)的角度來看待整合測試，PM 最是偏好用指標來衡量投報率與顯性價值等。
問題是，投報率、覆蓋率等這些指標，是極難衡量隱性的因子與其所創造的價值啊！ 試想想，該如何衡量軟體產品的彈性度、擴展性與維護性議題呢？
再則，整合測試與單元測試根本是兩種不同的構面與不同角色的人所負責的：
o 整合測試：產品釋出 (release)前涵蓋所有元件的測試，一般由 QA 品管專職人員擔任。
o 單元測試：系統開發期間對必要 (essential)性類別 (如 控制物件、資料存取物件、企業物件等)的測試，這必然由撰寫該類別的開發人員負責撰寫，不得假手他人。
所謂的單位測試框架 (Unit Test Framework)，其作用在於讓開發人員可以輕易地撰寫以「類 (Class)」為單位的測試程式，並隨時可以執行自動化的重複性測試 (automation repeatable test)，以確保該單一類別的正確性。
單位測試的創始者為 Kent Beck，其理論與方法已被各程式開發語言所接受並多以開源方式 (Open Source)釋出，作為xUnit家族的單元測試框架 (unit test framework)。
多數測試框架 (如 MSTest, Junit)已直接內建於 IDE (如 VS.NET 2015, Eclipse)開發環境內，使得開發人員撰寫與執行單元性的測試程式是一件輕易的工作；自 Visual Studio 2015，尤以免費釋出的 Visual Studio Community 2015 版本，均已內建更具多功能、擴展性佳的單元測試機制。
透過 Unit Test Generator，可以：
底下即為個人利用內建的 MSTest 測試框架 (Test Framework)所撰寫的最基本的測試程式碼骨架 (skeleton)，參考如下：