【從學員練習影片觀察到一個關於 TDD 的有趣現象】
極速開發的課後練習作業,雖說重點是放在極速開發要學習的技巧與刻意練習的模型,但開發的方式、順序也是刻意安排成類似 TDD 的進行方式,來讓生產力最大化(TDD 本來就是幫助開發的,不是幫助測試的)
我從2位第一次上我課的學員(當然就是 #極速開發,代表他們沒上過#單元測試 跟 #TDD與持續重構),雖然他們是照著示範影片、上課教學用 TDD 在寫整個 tennis 的過程,但從他們執行測試的時間點就可以發現:
「他是用測試來驗證 production code 的正確性」,即使他先寫了測試,也不先執行,沒有看到紅燈,每次都等到 production code 寫完了,應該要綠燈時,才執行測試。
而其他上過 TDD 課的同學 ,或是上過單元測試的同學,知道測試是用來描述情境,如果現在「加入的這個情境是新的需求或需求異動,代表目前 production code 還不支援這個情境,執行測試跑出的紅燈,就是等等 production code 要完成的 #目標」
test-frist 從來都只是 TDD 其中一個小小的衍生產物,而不是全貌。TDD, 測試驅動開發 從來都是一種開發方法,而不是測試方法。
總有些人老愛把 TDD 拿來跟測試相提並論,就總是喜歡把 test-first 當作靶子打,覺得違反人性跟直覺,覺得先寫測試在很多情況下是浪費時間或是不 work,可能拿來跟一堆測試的方法論相提並論,或總是只拿回歸測試的效益來當作 TDD 的整體。抑或是陷入 isolation unit test 與 integration test (其實就是非 isolation 等級、有實際依賴的自動測試)之爭。
```
註:TDD 事實上是可以不是單元測試等級的。
```
要比較正確看待 TDD 的角度,首先要知道它是幫助開發的、它是一種開發方式(當然不是唯一一種,甚至也不會是最好的一種,因為根本沒有最好,只有剛好)
接著要了解 TDD 可能用 IPO 模型還比較貼切,input-process-output,在你開發任何功能之前,你總要先想過這件事。而先想這件事,才是 TDD 的最基本精神。
接著是怎麼把你想好的東西,變成可執行的 spec,我們只是用測試程式來「描述」你腦袋中的「IPO模型」,把 process 的過程當作一個黑箱子。
而這個 IPO 模型在結合成「使用情境」,就會帶來「高易用性 API 的好處」,只有在一開始就先想好怎麼給別人用,最後才會好用。所謂的一開始想好,指的不是預先設計一堆 class,而是 input/output 想清楚期待(一般會結合實例化需求,搭配 Given/When/Then 的 gherkin style 來把前置條件、資料、前提想好,當發生什麼事,應該是怎樣的結果),然後描述它。在紅燈定義清楚目標,綠燈完成 input/output 關係且沒弄壞前面的所有情境後,來針對 process 進行重構(事實上 Kent Beck 的 TDD by Example 更多是用 refactor 來 #完成 process。
```
註:所謂的 output 不一定只有回傳值,包含外部依賴狀態、資料的改變,甚至顆粒度小一點,針對物件導向設計的話,物件內部狀態的改變也算,只是物件內部狀態改變,驗證點要嘛是拿得到內部狀態,要嘛就是要驗證物件哪個行為會因這個內部狀態而有所不同。
```
## 戰 TDD 之前該先做好的功課
要戰 TDD,是不是至少要把 Kent Beck 的 TDD by Example 看完?
要戰 TDD,請不要拿它跟測試方法論來比,那只是一下就被人看破手腳。因為它是個開發方法論。
要戰 TDD,請不要把它的好處只限縮在跟回歸測試、自動測試的比較,因為那只是它的衍生好處,當你試過在白海報紙上 TDD 就懂,TDD 是在釐清你的思緒的同時,又可以以終為始,確保你在 production code 的每一個動作都是為了滿足某個期待的情境。
要戰 TDD,請不要去把 單元測試、整合測試捲進來,那是測試的顆粒度,那是測試的分類,TDD 從來都不是只能限於單元測試。
要戰 TDD,請不要在那邊戰他是 bottom-up ,是直接從程式/class 的角度出發,事實上 TDD 既不是 bottom-up, 也不是 top-down, (書裡面就有講這件事咩),實務上的 TDD 結合倫敦派(GOOS)跟芝加哥派(Classic TDD),會更像 Outside-In 的進行方式,先定義好驗收情境,接著從最外部(也就是使用者看得到的部份)一路把依賴往另一邊的系統邊界推,直到推到系統以外的依賴資源(persistence 或 external API/service)
```
註: ATDD by Example 中 ATDD by Example, Kent Beck 寫的序最後的一段話。
Kent Beck:
「就像我曾說過的,TDD的一個缺點是,它可能會退化為一種用來滿足開發人員需求的編程技能。某些開發人員從更廣泛的角度來看待TDD,輕易在他們測試的不同抽象級別間跳躍。然而在ATDD中不存在歧義,這是一種加強與非編程人員溝通的技術。我們之間良好的協作關係,以及作為這種關係基礎的溝通,能夠使軟件開發更有效率。採用ATDD是向著溝通更清晰這個目標邁進的重要一步,而此書是一本全面又平易近人的入門讀物。」
```
要戰 TDD,請不要只關注在 test-frist,因為他只是用 test 來幫助你 think-first,不要邊寫邊想。然後不要過份依賴或相信你腦袋的能力,把你想好的東西具體化出來,最好可以被直接執行,最好除了你以外每個人執行出來的結果都會一樣(不管是對的,還是錯的)
要戰 TDD, 請不要把論點放在見樹不見林,如果你有看 TDD by Example 的 Part 1, Part 2 那兩個加起來共 24 個章節,就知道一開始就得把當下想到的全貌紀錄在一個「紙本」的 backlog (所謂的紙本,只是要講這並不依賴於任何工具)
而這個需求輪廓的全貌,會隨著你逐漸完成一部分一部分的情境,設計逐漸浮現後,而隨時跟著增減調整。
但不代表 TDD 就是先想到一個測試案例,就直接先幹下去了,那根本是亂搞。
以上這些,都還不是在列 TDD 的好處,而是針對那些從來沒搞懂 TDD 但又愛戰 TDD 的人一點提醒,你戰的很可能是「你誤解的 TDD」。
TDD 還有許多實務上的用途,列上我在譯者序中的一小段:
>> 測試驅動開發(Test-Driven Development, TDD)!一種以測試為開發輔助、以測試來描述需求情境、以測試來當作目標、以測試來表達期望、以測試來驗證疑問、以測試來實驗學習、以測試來溝通協作、以測試來協助設計高易用性 API 的「開發方法」。
譯者序有開放給大家看,請見:https://tdd.best/book/tdd-by-example/
拜託,要戰之前去看一下祖師爺 Kent Beck 對 TDD 的原始見解:https://www.tenlong.com.tw/products/9789864345618?list_name=srh
如果你想正確的使用 TDD 來幫助你在實務上產生許多的價值,帶來許多的好處,尤其是需求釐清、持續重構、小步快跑的部份,最好理解的培訓課就在這:https://tdd.best/courses/classic-tdd-by-example-video-training/
最後我想講一段話:
TDD 從來都不該被導入到團隊中,但它是一種很好的自我鍛鍊與學習的方式,也是一種能用很低的成本來帶來很多好處的開發方法(見下方註腳),然而它也不是適用所有的情況,但它可以讓『完美』變成一個動詞,而非不變的形容詞。
```
註:
Kent Beck 在 DHH 靠腰:《TDD is Dead》 之後寫的一篇反串文:《RIP TDD》
https://www.facebook.com/notes/1063422864115918/
我幾年前的簡易翻譯,通常也是 TDD 可以幫助你解決的問題,如下:
- Over-engineering (過度設計)
- API feedback (改善API的設計與可用性)
- Logic errors (想的跟寫的不一樣,寫的跟需求不一樣)
- Documentation (寫跟維護文件是痛苦的)
- Feeling overwhelmed (找不到切入點)
- Separate interface from implementation thinking (抽象設計)
- Agreement (確保已修正問題的證據)
- Anxiety (改東壞西的擔心受怕)
```
很久沒對 TDD 發表這種長篇大論了,因為不理解、不想理解、不同角度理解的人居多,能真的到各自的塔上用不同角度來看原義,以及實務上用它來幫助解決的問題有哪些的人,真的太少。
大部分人只想針對這個詞彙來攻訐以博得流量跟吸引目光,而不是想著「我可以用它來幫助我什麼」
問題跟需求是中性的,解決問題跟滿足需求的手段與方式有千萬種,不會只有一種,也不會有所謂的對錯,多點角度去了解不同的方法、方式,然後融會貫通,發揮綜效,在實務上用最少的成本與風險來產生最大的價值,這才是真正的目標。
導入敏捷不該是目標,導入 TDD 也不該是目標,目標永遠都是在實務上產生價值、解決問題、滿足需求。
同時也有12部Youtube影片,追蹤數超過1,310的網紅大象中醫,也在其Youtube影片中提到,地震 坍塌的現場 救難人員 在確定生命跡象定位後 小心翼翼的開挖 確定整個身體 整體都可以鬆動後 才會動手拖動 若是硬拖 就是一個魯莽的救難人員 即便局部拖出來 非死即傷 避免傷科裡面的暴力派 無法精準局部打擊時 移動不了整體 小心傷科裡面的軟筋膜派 所謂的軟傷科...
「見樹不見林」的推薦目錄:
- 關於見樹不見林 在 91 敏捷開發之路 Facebook 的最讚貼文
- 關於見樹不見林 在 Facebook 的最讚貼文
- 關於見樹不見林 在 一分鐘健身教室 Facebook 的精選貼文
- 關於見樹不見林 在 大象中醫 Youtube 的最佳貼文
- 關於見樹不見林 在 管碧玲 Youtube 的最佳貼文
- 關於見樹不見林 在 大象中醫 Youtube 的精選貼文
- 關於見樹不見林 在 [創作] 見樹不見林- 看板poem - 批踢踢實業坊 的評價
- 關於見樹不見林 在 成語/諺語時間: 只見樹木,不見森林【釋義】只考慮個別與局部 的評價
- 關於見樹不見林 在 見樹不見林(@deepmind) 的公開頁面 | Dcard 的評價
見樹不見林 在 Facebook 的最讚貼文
【專文】民意強烈支持新竹縣市合併,桃竹竹門當戶對,真的也可以合併!
文/楊鵬生(作家 醫師)
縣市合併議題常常被一些政治人物、意見領袖或名嘴簡化成是為了爭取比較多的統籌分配稅款,那是目光如豆,只見樹不見林;縣市合併的目的在事權統一,不會多頭馬車;當新竹縣長和新竹市長是同一人時,雙方根本不需要溝通,也可以說是每分每秒都在溝通;可以事權統一,綜合規劃,提升行政效能。
一般民眾比較在意的是每天的柴米油鹽醬醋茶,對於沒有明顯直接利害關係的公共議題,不一定很關心;並且絕大多數民眾是以自身利益為主要考量,例如無殼蝸牛希望房價跌,但是已經貸款買房的民眾則擔心房價跌。
#行政區合併
見樹不見林 在 一分鐘健身教室 Facebook 的精選貼文
【閒聊】我的觀念演變
體重控制是複雜的現象,神經系統、內分泌、基礎代謝率、腸道菌、脂肪代謝都參與其中。
鑽研這些現象固然很有趣,但也容易見樹不見林。
間歇性斷食、低醣、原型食物、代餐包讓你變瘦了?因為它們降低了總熱量攝取。
代謝率下降?不用煩惱,因為除了運動之外,目前尚無有效提升代謝率的方法。
慢性發炎、腸道菌失調、胰島素敏感度變差?不用煩惱,這些問題瘦下來之後就會跟著改善了。
只要飲食能降低熱量攝取、提供飽足感、維持起來不會很痛苦、很麻煩,你就能順利瘦下來。
所有減重法都是走「降低熱量攝取」這條路,沒有例外的。
見樹不見林 在 大象中醫 Youtube 的最佳貼文
地震 坍塌的現場
救難人員 在確定生命跡象定位後 小心翼翼的開挖
確定整個身體 整體都可以鬆動後 才會動手拖動
若是硬拖 就是一個魯莽的救難人員
即便局部拖出來 非死即傷
避免傷科裡面的暴力派 無法精準局部打擊時 移動不了整體
小心傷科裡面的軟筋膜派 所謂的軟傷科 也常造了太大浪 晃動患者太過
平日健身房好好人 可以彎來摺去扯拉中軸筋膜
一旦 進入長照 骨鬆筋攣縮 的地震坍塌現場
傷科操作模式 就要改成 太極拳模式
功法的目的
在於如實解決問題 嚴肅對待問題
臥床 坐輪椅 等待走向生命終點的人
值得 功法 嚴肅對待
中醫傷科的整體論
用在 鬆背
用在 推肚子
內輪差殺人
就是 四個輪子 無法等速 無法等比例連動
中醫傷科在醫者鬆背 靠造大浪 刷存在感時
會造成患者身體 各部位不成比例 的搖晃
雄兔腳撲朔 雌兔眼迷離 支離破碎 見樹不見林
拖不動患者整體
此謂內輪差殺人
傷科 醫者 搞的
一次殺一點
鬆背 與 推肚子
學者在一開始 就要學對
就是那一丁點
追求的是 諧和
追求的是 頻率共震
不追求 壓到酸痛
若在學傷科的最初 就以傷科華麗技巧 大場面為能事
不能安心在窄空間 小動作上 探尋
在一開始 就會是一場 美麗的學習誤會
![post-title](https://i.ytimg.com/vi/H3trirjnrVk/hqdefault.jpg)
見樹不見林 在 大象中醫 Youtube 的精選貼文
肩關節的正確伸展
要練的 並不是 誰的肩關節較柔軟
而是 誰可以成就 整個身體的太極球體 整體轉動
才是 肩關節的正確伸展
這是 以傷科手法 去 處理內科疾病 的正確邏輯
不在小小的調筋骨 理筋膜 上糾結
要在 以肩關節 成就太極球體上練習
要從 長照觀點 去看待自己的肩關節 能否伸展?
而不是 以自己的青壯年 肩關節能轉為能事
要假設自己 萬一中風 肩關節 不能轉動 不能上舉情形下
還能否轉動太極球體 去閃過路邊衝過來的一條野狗
這是 以傷科思維 去嚴肅討論內科
去治長照的未病
若只是以健保傷科 去看待 五十肩的肩關節
見樹不見林
長照時 一個肩關節卡住孿縮 醫院復健多年束手無策
連起身都困難 一走路就跌倒 注定坐輪椅
![post-title](https://i.ytimg.com/vi/7K9QGza6888/hqdefault.jpg)
見樹不見林 在 成語/諺語時間: 只見樹木,不見森林【釋義】只考慮個別與局部 的推薦與評價
樹木比喻細節或局部,森林比喻整體或大局。當我們近看觀樹時,就只能看到局部,而忘了要遠看整個森林,才能掌握事物的全部真相。總而言之,見樹又見林才能夠全面。 No ... ... <看更多>
見樹不見林 在 見樹不見林(@deepmind) 的公開頁面 | Dcard 的推薦與評價
見樹不見林. @deepmind. 1 篇文章・0 人追蹤. 追蹤. 網路不穩. Belly 抱歉……目前網路不穩或伺服器忙碌中,喝杯香蕉牛奶再重新試試吧! 重新載入. 見樹不見林. ... <看更多>
見樹不見林 在 [創作] 見樹不見林- 看板poem - 批踢踢實業坊 的推薦與評價
我不是山老鼠
不是伐木工
不是傢俱業者或
古董商
為什麼要為了整片森林
放棄一顆棲身的樹
我想當啄木鳥一輩子
入木三分
死的時候化為它的養分
他們總說多看一些才能分辨
好的壞的
我現在就只要這一個
誰管他是好的壞的
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.140.178.17
※ 文章網址: https://www.ptt.cc/bbs/poem/M.1488715652.A.6B4.html
... <看更多>