[爆卦]單元測試的藝術天瓏是什麼?優點缺點精華區懶人包

雖然這篇單元測試的藝術天瓏鄉民發文沒有被收入到精華區:在單元測試的藝術天瓏這個話題中,我們另外找到其它相關的精選爆讚文章

在 單元測試的藝術天瓏產品中有7篇Facebook貼文,粉絲數超過1萬的網紅91 敏捷開發之路,也在其Facebook貼文中提到, 今天終於劃掉待辦清單中,歷時 4 ~ 5 個月的待辦項目啦!(中間大概有40個小待辦) 相關網址:https://tdd.best/book/tdd-by-example/ (天瓏可預購) 翻譯還是很花時間,這讓人挺痛苦的。即使我已經這麼熟悉 TDD,這書翻起來還是吃力。(程式碼是最好懂的語言了...

  • 單元測試的藝術天瓏 在 91 敏捷開發之路 Facebook 的最讚貼文

    2021-01-22 18:56:43
    有 155 人按讚

    今天終於劃掉待辦清單中,歷時 4 ~ 5 個月的待辦項目啦!(中間大概有40個小待辦)

    相關網址:https://tdd.best/book/tdd-by-example/
    (天瓏可預購)

    翻譯還是很花時間,這讓人挺痛苦的。即使我已經這麼熟悉 TDD,這書翻起來還是吃力。(程式碼是最好懂的語言了)

    最難翻的是文字很少又語帶雙關的章節標題,其次是 1980 年代的哏,反而對 Kent Beck 自言自語式的描述感到熟悉,因為我自己也很習慣會這樣寫東西。

    最後,我最想感謝的,還是 Kent Beck 同意我的提議,允許我把書裡面每一個範例的演進過程,都放到 GitHub public repository 的 commits 裡面,因為看到全貌很重要,看到差異也很重要,只看書是很難透過自己的腦袋記住這些全貌的。

    就如 TDD 最有用的地方之一,就是讓你可以專心專注在單一個東西上,心裡既有全局,又可以專注,又可以安全可靠,又可以從任何一個點重新再來。

    當時買了 https://tdd.best 的 domain,就是因為接下來翻譯這本書的任務。我對這本書,心裡是感到有點責任的。就像 2017 年翻譯《單元測試的藝術》一樣,我深信這能為台灣軟體業、開發人員帶來本質上的改善。

    這是一本 2002 年的老書,Kent Beck 在寫書時就已經用當年的 Python TDD 出 xUnit 的原型。你沒看錯,用 TDD 來測試驅動開發出它自己的 test framework。

    我們,還要落後這個世界現代的開發方法多少年呢?

    #KentBeck的測試驅動開發

    --
    感謝博碩出版社買下版權,感謝編輯 Sam 能讓大家在農曆過年前能買到這本經典鉅作來看。(應該來得及)

  • 單元測試的藝術天瓏 在 91 敏捷開發之路 Facebook 的最佳解答

    2020-05-30 22:32:34
    有 112 人按讚

    《修改軟件的藝術》
     
    進行一個預期九個月的專案,到第八個月時,我們發現進度比預期晚了六個月。問題在哪?怎麼會變成這樣的呢?
     
    其實我們一直是晚了六個月,只不過我們到第八個月才發現罷了。
     

    敏捷迭代的重點,讓你不斷再次確認目標是否產生變化,是否要調整方向步伐,我們是否能如預期般達成目標。
     
    如果不行,在目前的情況下,我們能做什麼是最有價值的行動呢?
     
    在這過程中,避免因為工作任務顆粒度過大,導致資源無法釋放,無法因應變化去選擇有更價值的工作進行,因此承擔機會成本。抑或是得把已經投入資源進行開發,卻仍無法產生價值的半成品放一旁,因此承擔了沈沒成本。
     
    越早發現問題,修復問題的成本與風險越低。頻繁確認目標以及實際的落差、頻繁交付價值、調整行動,這才能應對現代軟體產品的變化性。
     
    我喜歡這本書,也推薦給想要體會在遺留代碼系統中的敏捷實踐為何的朋友。九個實踐如下:
     
    1) 在問如何做之前,先問為什麼做、給誰做、做什麼。(user story template)
     
    2) 小批次建置,每一段之間都是自動化的鐵路,異動量少,建置發生問題時,根本原因越容易找出來,能得到更快的 feedback ,就能更快的做出反應。
     
    3) 持續整合(Continuous Integration), 持續整合說真的跟 build solution 用哪一套的關係不大,重點在團隊能在多快的時間內讓大家寫的程式變成一份並確認執行無誤。
     
    持續整合的有效性與即時性也絕對跟你團隊的分支策略有關。(建議基於主幹的開發)
     
    4) 協作,如何透明順暢頻繁地溝通,又不會花太多無謂的溝通成本,如何確保大家的程式碼理解一致、閱讀無誤。extreme programming 裡面有非常多良好的實踐可以解決這些問題。
     
    5) write clean code,高內聚、低耦合,職責明確,互動簡單,意圖清楚。(簡單設計simplicity 的四條原則)
     
    6) 測試先行,test first, 其實是 think first, identifying requirements first. 在你動手寫產品程式碼之前,總要先搞懂需求的期望是什麼,需求怎樣叫完成。
     
    要滿足使用者哪些情境,才叫符合預期。(這就是驗收測試驅動開發, ATDD)
     
    這才是我們為何要寫程式的目標,接著以終為始,從 ATDD 往下 drill down 多個 TDD 循環以完成所有情境的程式碼,並在每個 TDD 循環中,一分不多一分不少的把力氣花在該花的地方上,並且在每一次的綠燈情況下進行重構。(包含測試程式)
     
    這,才是實務上會 work 的 TDD,這才是為什麼 TDD 是種開發方法論,而不是測試方案。
     
    7) 用測試描述行為,事實上 test-first + test as scenario, 怎麼把繁複的需求功能抽絲剝繭成關鍵情境,並進行排序來達到 baby step 的效果,到這邊6+7 就是 實例化需求(specification by examples)+驗收測試驅動開發(ATDD)+測試驅動開發(classic TDD, 紅燈、綠燈、重構)
     
    8 ) 最後實現設計,意圖導向設計,重構、重構、重構,你得知道怎麼辨識出 code smell, 你得知道重構技巧,你得知道怎麼用最短時間、最低風險,正確地重構你的設計,來讓用的人很好用,看的人很好懂,改的人很好改。
     
    這邊要避免不必要的過度設計,又是一整門學問了。(過度重構也是一種浪費,通常是以 #過度解耦 的模樣呈現。)
     
    9) 從遺留代碼中學習,耐住性子去尊重這些遺留代碼。他們過去有其存在的價值與原因,至少你的薪水可能就是這堆線上又髒又臭的代碼在幫你賺的。
     
    一定要壓抑住自己重寫系統或功能的衝動。
     
    重寫跟重構不一樣的,重寫在實務跟價值上是不會 work 的。
     
    而且,如果每次碰到遺留代碼就想重寫,你就永遠無法具備重構實務產品的能力。
     
    當然,重構之前一定要有測試保護,這也是為什麼你該學的單元測試,是 #針對遺留代碼 如何優雅低風險低成本的加入單元測試。
     
    沒有單元測試的保護,沒有單元測試提供的反饋(自己能做到的獲得最快的反饋實踐就是單元測試),就無法「快速進行較進階的重構」
     

    當然,以上有蠻多是書裡沒提到的細節,也是我上課會提到、甚至設計成 workshop 的內容。
     
    寫著寫著沒想到寫這麼多,沒辦法,共鳴點太多了,裡面真的沒啥廢話,也沒啥太打高空的東西。
     
    都是扎扎實實該落地的實踐,要想當個基本功紮實、穩定輸出戰力,要想領的比別人多,就得比比別人具備更多能產生價值的能力。
     
    不要再被你身邊的環境或公司受限住了,那都是你下意識給自己的藉口理由。
     
    你覺得這些東西在你現在的公司工作用不上,所以你不想學。
     
    但因為你不學、不會,又怎麼進得去把這些東西發揮地淋漓盡致的公司呢?人家怎麼會願意用你呢
     
    👉 修改軟件的藝術,請參考 天瓏資訊圖書 上的介紹, https://www.tenlong.com.tw/products/9787115467768
     
    ※ 對實踐 5,6,7,8,9 有興趣,想透過實作了解的更透徹的朋友,可以參考底下兩門培訓:
     
    1)演化式設計:測試驅動開發與持續重構 202009,https://dotblogs.com.tw/hatelove/2020/05/08/202009-Evolutionary-Development-TDD-and-Continuous-Refactoring
     
    2)【針對遺留代碼加入單元測試的藝術】202011,https://dotblogs.com.tw/hatelove/2020/05/08/Unit-testing-effectively-with-legacy-code-202011

  • 單元測試的藝術天瓏 在 91 敏捷開發之路 Facebook 的最讚貼文

    2020-05-23 13:16:45
    有 144 人按讚

    我想 highlight 的部份是這幾段:

    --
    【Part 1】
    近在實驗室做專案時,因為我們的開發的軟體都有寫單元測試,但是我發現我們好長一段時間,常常因為改了一點程式就必須維護我們的單元測試好久。

    每次維護UT時我們都瀕臨崩潰的狀態,實在花太久的時間了!

    完全已經影響到我們開發的進度了。

    於是終於有一次我終於忍不住了,我把團隊的所有開發停下來,我說我們來開個 #檢討會,為什麼我們每次都需要花這麼多時間在維護UT?

    我跟他們說,因為我們UT的品質很差很差很差!!!

    我們達成共識,決定要把UT重新設計。

    ※ 91 comment:這其實就是持續改善,跟 retrospective 的概念一樣,其實我們工作中一直會碰到很多人其實感覺到問題,但是不想講、不想問、不想改,就繼續在心裡面幹,對實務於事無補。 #因為他們覺得這是環境的問題

    沒有時間停下來看問題在哪,最終只是把產能都浪費掉了。

    --
    【Part 2】
    當天我熬夜把如何撰寫可維護性的單元測試的方法讀完,隔天分享給團隊。

    我們討論完後 #立刻開始改程式,不僅我們的單元測試變得乾淨簡潔,也更有彈性好維護。

    我們那天寫了一些新的程式碼,而我們要加入一些測試案例測試我們新寫的程式

    以過往經驗,寫一個測試案例大概要花20~30分鐘,有時候甚至得花到1個小時的時間

    但是那天我們實測,#我們只花不到三分鐘就寫完一個測試案例了。

    我們的測試不僅提高了可維護性,也伴隨著提高了我們可信賴的及可讀性

    當下只有一個字可以表達我的心情就是『爽』

    ※ 91 comments:只有看書沒啥屁用的,只有分享也沒用的,立刻動手改程式,有行動才能驗證學習的有效性,也才能產出價值。

    但他們其實真的蠻厲害的,因為《#單元測試的藝術》如果真要說少那一部份,我覺得是 #重構測試,但重構自己就可以是一本書了,放不進來也是合理的。

    我只是想強調,測試沒有重構,那一堆死掉發臭的測試程式,也會是拖累團隊這艘帆船的另外一個巨大船錨。

    --
    雖然我不是作者,只是譯者,但看到能這樣對他們實際工作產生幫助,還是很欣慰的。

    補上天瓏購書連結:https://www.tenlong.com.tw/products/9789864342471

    忘了提,十一月梯次還有位置:https://dotblogs.com.tw/hatelove/2020/05/08/Unit-testing-effectively-with-legacy-code-202011

你可能也想看看

搜尋相關網站