BDD Workshop

改A壞B

需求一直改

Ruddy老師說過的話，一位信仰敏捷的人，是會認清這個事實：
「你無法凍結需求，正如你無法凍結市場、競爭、知識、進化或者成長一樣。」

用正確的心態面對異動

維護前人的專案，不安感很重

要花好多時間找錯誤

上線前一刻才發現問題很多

無法評估這次的異動會影響那些

....

不寫測試的推託說詞

功能都寫不完了，沒有時間寫測試

寫測試會讓專案Delay

你可能搞錯對象了

需求不明確，幹嘛要花時間寫測試

因為，寫了測試還是沒辦法達到User需求阿，幹嘛寫它

為什麼需求不明確就要開始寫程式?而不是先釐清問題?

測試的重點不是寫測試，而是需求

這個功能很簡單還需要寫測試嗎

但其實是，最簡單的事往往最花時間

一個簡單的需求，大家的想法就不一樣..

為了避免浪費，必須要做需求確認

最有效確認需求的方法之一就是利用測試個案. 就像是在測試一個系統一樣, 來測試需求是否正確. 也就是說, 你可以用範例來闡釋需求, 把範例變成測試, 然後使用測試驗證需求」

只要有Production Code，就應該被驗證，而不是用簡單與否來當旗標

為什麼覺得不容易執行

測試寫了，還是沒有辦法滿足使用者的需求

心理障礙，不習慣改變、害怕、質疑

不知道如何開始

主管不挺

寫好的東西要不要測?

既然要測，為何不挺?

其實你一直都在寫測試

開發、維護時

在UI彈跳出一個警告視窗，觀看視窗的結果，看完了(人眼比對)再把它註解起來

對表單的CUD操作，會開啟SSMS，針對需求下Insert、Update(還原)、Select(人眼比對)，存檔，然後下次就忘了這段Script在是幹嘛的，然後再重寫一次..

需求異動時

把UI打開，將所有的按鈕都按過一遍，下次需求異動的時候，在手動按過一遍

好花時間、好麻煩阿，最後，只針對那個需求按A按鈕

結果，A功能改好了，但BCD功能壞掉了，可怕的是BCD壞了你還不知道....

以前的測試方法做不到

上述的動作都是憑開發人員的心情、直覺，只有開發人員當下的狀態才知道，日後沒有人知道開發人員怎麼做，包含開發人員自己也沒辦法在短時間之內知道

用這樣的方法你知道程式碼異動後影響的範圍嗎?

你需要用多少時間知道哪些程式被影響了?

思考一下，既然測試都是要做的事，這樣的方法不但沒有效率，還會影響品質

你誤會了，F5是偵錯，不是測試

一個好的測試程式碼有幾個特性

能自動化，可重複執行

任何人、任何地點都能運行

結果是穩定的，不會因為環境而影響結果

你以為你在開發，其實是在創造臭蟲...

自己創造Bug，自己解開Bug

寫好的功能，沒有使用案例，很快就忘記這個功能是幹嘛用的

有些開發者會習慣於暫緩程式的驗證，他們總以為進行程式的開發遠比進行測試驗證還來得要有生產力，甚至在面對時程的壓力時，會選擇省略功能測試，期望以整合測試或系統測試來將測試問題延後處理

測試作業太慢開始、程式碼之中散佈著因為需求或設計規格、或實作結構問題所產生的一些疏漏或錯誤，這些現象使得程式瑕疵擴散或蔓延的速度比修正的速度還來得快。當程式的瑕疵愈變愈多、除錯就會顯得更困難，對程式的除錯與測試都是個沉重的負擔，更不用說可以及早發現程式中的瑕疵了。

不要用臆測的方法來除錯

用使用案例來取代

使用案例

要有三個東西

輸入資料

執行步驟

驗證執行結果

用使用案例來開發的好處

確保程式真的能動

需求異動或改善系統的時候，不怕系統被改壞

縮短找Bug的時間，快速地找出問題

就是一種使用範例

功能(目標)，團隊能有一致的共識，不會各自表述

釐清需求問題，減少浪費，縮短開發時間

測試程式可以變成可交付的文件

提升軟體的品質

提升開發人員設計物件的能力

寫測試的重點是在於隔離技巧(mock)，這技巧學會了，設計物件及架構的能力無形之間就會提升

為什麼用使用案例會減少整體開發時間

寫使用案例是為了減少你的測試時間用的，減少測試時間進而減少整體開發時間，那你為什麼不做呢？

釐清需求減少浪費

使用案例能取代以往的文件嗎

不能

可用來補足以往文件的不足

開發人員最討厭的事

沒有文件

文件和程式對應不起來

當你學會用使用案例當開發技巧，你還會再多討厭一件事

隔離

解除耦合、降低相依

IoC

IoC (Inversion of Control)反轉控制

由外部決定物件生成的方式

SOLID的D，依賴倒置原則 (D.I.P)

DI

DI (Dependency Injection)依賴注入

DI就是實現IoC的技巧

DI (Dependency Injection)實現的方式

欄位
屬性
方法
建構函數
委派
介面
IO(檔案、SQL)

InternalsVisibleTo

讓特定的專案(Component)，可以存取 internal 的成員

用在測試

NSubstitute

Mock Framework

用來動態建立模擬物件，然後注入目標

必須是 interface 或 virtual

驗證

3A 原則

Arrange

Act

Assert

從你自己開始跨出第一步

不會課聽完，你就不會卡關

甚麼情況下不要寫測試

補測試的時機