【Kent Beck 的測試驅動開發,書籍勘誤】ch14, p.79 漏了一段測試程式碼。
如圖,感謝讀者回報問題。(可能要等第三版才能更新這個部份了,抱歉。)
相關資訊請見:https://tdd.best/book/tdd-by-example/
前兩個章節的勘誤第二版應該可以修正。
Tags: kent beck 的測試驅動開發
91 敏捷開發之路
About author
我是 Joey Chen,闖蕩江湖的稱號是 91,熱血點火師,專門燃起大家心裡面的熱情與初衷。
目前為 Odd-e Taiwan 的負責人,同時也是 JetBrains 在台灣的培訓夥伴,至今也仍是熱愛學習與享受各種程式語言之美的 programmer。
身為敏捷教練,擅長 Agile、Scrum、LeSS 等敏捷文化與協作框架的落實與導入,如何讓大家 being agile 而不是 doing agile。同時喜歡結合各家所長,例如 Lean, Kanban 等,重點是持續改善、解決問題、端出成果,而不執著於某種特定方法論或框架。
身為技術教練,我也是極限編程(extreme programming)的狂熱者,我擅長用這些技術與工程實踐來提昇產品的品質、團隊的生產力、降低營運風險,因應市場與公司的商業目標,讓團隊能具有高適應與反應能力的基礎建設。例如 實例化需求、ATDD、BDD、TDD、重構、自動化單元測試/整合測試/驗收測試、CI/CD、code review、pair programming、mob-programming 等等。
同時,我也是推崇 極速開發 的 developer,追求從想法到產品程式碼的完成,中間的時間差能趨近於零,也就是劍隨心轉,想到哪,程式碼就長到哪的境界。從想法到實現中間的等待,其實在實務上佔了很大的 context switch 成本,如果能讓這段時間縮到最短,就能比其他人多嘗試更多種解決方案,進而挑選出最剛好的方案。
同時也是技術社群的活躍份子,從 2010 年開始連任九屆的微軟 MVP,兼任 MSDN 論壇板主,也曾經獲得年度 MSDN 文件庫刊登數量世界第一的榮耀。對微軟技術有愛,對 C# 有愛,對自動測試有愛,對重構與設計模式有愛。近年來對 Java, PHP, Python 也充滿濃厚的興趣,曾帶領客戶團隊中不會寫程式的 QA ,一起用 Python 完成超過百個 mobile UI 自動化測試。
擁有超過十年擔任開發團隊 tech leader, trainer, coach 與 mentor 的經驗,進行的企業內部與公開技術培訓課程已超過 100 場,培訓過的開發人員超過 1000 位,擔任研討會與社群活動的講師次數超過 30 次。
同時也是技術書籍的作者與譯者,與朋友合著的書籍包含《ASP.NET MVC 5:網站開發美學》、《ASP.NET MVC 4 網站開發美學》,翻譯的書籍有《單元測試的藝術-第二版》、《敏捷開發實踐》、《進入IT產業必讀的200個 .NET面試決勝題》。
如果想跟我即時互動,歡迎直接私訊或 email 至 [email protected]。
請參考:https://tdd.best/about/
請參考:https://tdd.best/about/
kent beck 的測試驅動開發 在 [心得] RIP TDD(BY Kent Beck) - 看板Soft_Job - 批踢踢實業坊 的推薦與評價
前言:
本翻譯有翻譯不精準且有自行增添字眼,請邊參考原文對照著看。
https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847
=============
TDD是一種用測試來進行開發的模式,所以他的本質其實是為了開發而非測試。
Kent Beck(設計模式的先驅者)在RIP TDD裡舉出了8個你應該使用TDD的理由。
1. Over-engineering(過度設計):
EX:
今天你被授命要做一個會員登入的系統,你老闆只要你串facebook登入,結果你多寫了一個google登入。
這樣就過度設計了,程式碼裡不要擺用不到的東西,會造成後面維護上的困擾。
TDD每一個測試都是需求,而你不應該寫需求以外的程式,TDD力求以最簡單的方法讓測試通過。
2. API feedback(介面回饋):
因為TDD會根據使用者的需求寫測試,當你發現 你的介面不敷使用於測試時,就會去修改介面,這會使你的介面越來越貼近使用者。
3. Logic errors(邏輯錯誤):
TDD裡面不會有任何的邏輯(if else)判斷,所以如果出來的結果不符合就是你的method有問題。
而且TDD一次只會有一個測試失敗,所以一定是你剛增加的code有問題。
4. Documentation(文件):
每個工程師都會跟你說他討厭程式沒有文件,但實際上會寫文件的很少,後面會繼續維護的更少了。
TDD的測試即文件,當你看完測試你就會瞭解這隻程式怎用了。
而且如果需求改變,你的測試也會改變,就會很自然地維護它了。
5. Feeling overwhelmed:
標題無關。
TDD的宗旨是先寫測試在開發,意味著即使沒有程式依然可以先寫測試,
6. Separate interface from implementation thinking(從邏輯來實踐獨立介面):
EX:
今天有個需求是串金流API,但是開發API的人說他要等上線前10天才能給你測試。
TDD遇到這種問題時就會做一個介面,測試時實作這個介面,去模擬API的行為。
這樣你就不用因為別人拖延自己的進度。
7. Agreement(同意)
當你把需求解掉了以後,你要如何說服發出需求的人妳已經把問題解決掉了?
顯然用測試是一個好方法。
8. Anxiety(焦慮)
當老闆問你一切是否OK時,TDD可以不用讓你提心吊膽的說OK。
工商廣告時間XD:
https://skilltree.my/events/mbh
十分推薦,我覺得每個程式設計師都應該聽聽TDD,而91的課淺顯易懂,
絕對讓你滿載而歸。
我本身就是學員之一,聽完有如獲重生的感覺。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.30.31
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1446442345.A.17D.html
更何況套一句FB流行的話。
你有想過QA測你的程式的心情嗎?沒有,因為你只想到你自己。
沒有測試的情況下,你敢跟QA保証說沒有任何錯誤嗎?
※ 編輯: y2468101216 (118.163.30.31), 11/02/2015 13:57:41
我打算有空就翻譯這樣。
※ 編輯: y2468101216 (118.163.30.31), 11/02/2015 14:36:10
再強調一遍TDD是開發模式,只是他利用測試作為開發工具,一魚兩吃。
phpunit好用很多。facebook/webdriver的文件寫的就是比nightwatch.js爛。
我最近應該會fork facebook/webdriver的example,2年前的範例到現在都不能用了= =。
※ 編輯: y2468101216 (118.163.30.31), 11/03/2015 09:22:10
... <看更多>