Dev 2Share

我在2010年寫了「程式內的防呆之道」; 現在讀來, 覺得內容略嫌冗長, 恐怕性急的讀者不想看。所以我就把我最近寫的一個 Unit Test 程式拿來當作實例操作, 順便聊一下「開發」與「防呆」二者如何可以相輔相成。

作為一個由技術支援工程師和 QA 轉任 Developer 的資訊從業者, 我從很早就認識到一件殘酷的事實, 那就是測試是個苦差事 - 至少比多數軟體主管和部份軟體開發者所以為的還要辛苦。我不想倚老賣老, 但是我發現很多沒有真正從事過測試工作的開發者, 好像並沒有真正思考過測試工作的難度。在他們心中, 如果談到測試, 雖然會理所當然的認為一定要做測試, 但是...

在 MSDN 對單元測試的介紹中, 對單元測試的做了基本的介紹。站在我這個 former QA 的角度來看, 一般人如果只是照著上面的簡單介紹去做單元測試, 然後就以為單元測試只不過是這樣而已的話, 未免把單元測試看得太單純。事實上「使用資料驅動的單元測試」才是真正實用的。怎麼說呢? 因為, 如果我們不是餵給測試單元很多預先知道結果的測試資料去進行測試的話, 所謂的「自動化測試」只是空談罷了。為什麼團隊裡面必須有 QA 存在? 就是因為我們需要 QA 站在開發者的對立面, 試圖去找出開發者沒注意或甚至沒想到的弱點; 有攻有防, 才能確保產品的品質...

單元測試 (Unit Test) 是一個很基本的工作, 如果你使用 Visual Studio 做為開發工具的話, 建立單元測試專案是一件再簡單不過的事了。不過, 除非你已經對單元測試很熟悉, 否則有些最基本的概念, 你最好能事先熟悉一下...