[30天快速上手TDD]目錄與附錄

30天快速上手TDD的系列文將帶著各位 step by step 從 ATDD/BDD, TDD 所需要的基礎打起,包含了 isolated unit test, web test, test framework 的介紹, refactoring, simple design, TDD 與透過 specflow (cucumber) 來做到 requirement, testing, design, liveing documentation 的結合,畢其功於一役。

這篇也為各位讀者整理了學習 TDD 的推薦書籍當作補充參考資源。

[隨筆] Developer 自我養成之路

  • 4059
  • 0

在軟體開發這一條路上,developer 可以從哪幾個方向去累積自己成長的能量,怎麼樣可以避免自己見樹不見林。

這篇文章分享我個人的一些經驗,希望能對茫然的開發人員們,提出多一點的角度供大家參考。

[隨筆] TDD 是一種修煉過程

學會 TDD?用 TDD?落實 TDD?到底什麼時候該用 TDD 呢?

TDD 其實是一種修煉的過程,讓你可以在每一次寫程式的過程,都逐步在累積功力,就像金庸的射雕英雄傳中,馬鈺教郭靖修煉內功的方式,無外乎就是一些呼吸、走路、睡覺的法子。

[隨筆] 學問-該怎麼提高上課的學習效果?

  • 853
  • 0
  • 2016-05-25

有許多朋友透過上課跟參加教育訓練來加速自己學習成長的速度,而也有很多朋友常問我,怎麼樣可以讓上課的學習吸收效果最大化。

這篇文章簡單整理我的兩個想法:

  1. 學習發問
  2. 練習回答

當你願意身體力行這兩件事,自然知識就會從講師的外顯知識,到你的知識內化過程,透過回答問題跟文章記錄,就又會經歷一次由自己發動的外顯知識過程。這樣的經歷,才能確保自己真的理解。後續當然就是要透過不斷地練習,才能達到實務上真正的內化。

[Unit Test Tricks]Extract and Override Protected Function with Moq

之前介紹了 Extract and Override 的技巧,使得不需改變 production code 對外的 API,也仍然可以在測試專案中建立一個 SUT 的替身,覆寫想要 isolated 的 dependency 就可以針對 SUT 做 isolated unit test 。

但手刻 SUT 的替身總是不如 mock framework 看起來便利,這篇文章要介紹使用 moq 來節省手刻 SUT 替身的 effort, 直接透過 moq 來 stub SUT protected virtual 的方法。

[Unit Test Tricks] Compare Object Equality

實務上撰寫的測試程式中,幾乎都需要針對 reference type 的物件或集合進行比對,然而大部分的 test framework 所提供的 Equals function 都是呼叫物件的 Equals(),也就是若沒有額外覆寫,仍然是比較 reference 的位址是否相等。

這篇文章介紹一個 Nuget 套件: ExpectedObjects,讓我們可以用簡單的 API 來針對物件、物件集合、組合式物件比較是否相等,還額外提供了部分比較的功能來因應實務上的需求。

[隨筆] 你的程式碼活著嗎?

什麼是 legacy code? 沒有自動測試保護的就是 legacy code 。

-Michael Feathers, 《Working Effectively with Legacy Code

講直白一點,legacy code 就是沒爹沒娘沒靠山,被人射後不理的產物。

誰都可能欺負它、弄壞它,簡直就是一直像死了般卻仍在線上活著的產品程式碼。

Scrum Estimation-Scrum Estimation Model

如何讓 scrum 團隊透過 t-shirt size 來對專案範圍進行相對估算,使用 yesterday's weather 來評估團隊速率,進而估算出推估時程與預計的 deadline 之間落差有多大。

當專案面臨「插件」、「時程調整」、「priority調整」、「需求異動」、「作法異動」、「人員異動」時,就能以 estimation model 當基底來評估影響範圍,讓團隊能在在變化當下擬定眼前最佳化的決策,並提供相對客觀的資訊給 PO 與 stakeholder 溝通。

Scrum Estimation-如何估算專案時程

當瞭解單一個 story 怎麼使用 relative estimation 的原則估算出 story point 後,這篇文章將介紹怎麼運用同樣的精神,針對整個專案的時程進行推估。公式只有一個,而且再簡單不過了。

時程(schedule) = 範圍(PBI story points) / 速率(velocity)

[隨筆] TDD 的哲學之道

TDD 是一種限制的美學。

  • 因為限制,所以美
  • 因為限制,所以快
  • 因為限制,所以聚焦
  • 因為限制,所以好懂
  • 因為限制,所以你知道自己正在哪裡,並朝向哪裡而去。

[Unit Test Tricks] Static Setter Injection

在實務開發中,常使用簡單工廠(Simple Factory)以及策略模式(Strategy Pattern)來封裝實作細節,使得 context 流程抽象穩定,並達到開放封閉原則(Open/Close Principle, OCP)中所蘊含可抽換實作的彈性。

在 context 流程中,透過簡單工廠依據條件來取得 interface 的 instance 固然美好,卻往往因為與簡單工廠的 static function 直接耦合,而導致這段 context 流程無法進行 isolated unit test。

這篇文章的小技巧,就是要解決 developer 因可測試性而廢棄簡單工廠不用,反而大費周章改用抽象工廠(Abstract Factory Pattern)的問題。

Scrum Estimation-Dog Point Game

對於第一次接觸 Scrum 或 Planning Poker 的團隊,在一開始的估算過程中,往往會產生一些摸不著邊際或尷尬的場面。大家不曉得到底該怎麼比較,比較的基底為何?我這樣估會不會跟大家不一樣,不一樣時是不是應該從善如流,下一次就跟大家估一樣?當估得比其他人高時,是不是我就顯得能力比較弱?這些疑惑,會使得團隊成員不容易享受於輕鬆輕快的估算流程,而影響了團隊的節奏。

因此,本篇文章將介紹一個基於相對估算的簡單遊戲:Dog Point。透過把軟體開發中的 story 轉換成小狗的情況,來幫助大家瞭解估算的運作方式、意義。

[Unit Test Tricks] Extract and Override

當 legacy code 不具備可測試性,又想為其建立 isolated unit test 且不影響所有使用到這個 class 的場景端,可以透過 extract and override 的手法,使用繼承+覆寫,就能達到很有效益的 isolated unit test ,是針對 legacy code 撰寫 isolated unit test 最好用的技巧之一。

Scrum Estimation-Story Points and Planning Poker

要怎麼估算需求需要多費多少時間完成,要怎麼讓 PM/PO 與 team 可以快速達成共識,要怎麼避免人事物的干擾因素,這篇文章說明了在 Scrum team 中估算的方式、時間、效益、參與人員等…即使不是使用 Scrum ,也可以依據這些概念來找到最適合您們團隊的估算方式。