開卷筆記 – Specification by Example

spec_by_example

這本書看的是中文版。本書談的其實是 BDD/ATDD,但為免太技術而另生一堆用詞,因為 BDD/ATDD 想要和能達到的目的,是一個讓軟件開發的各個關係人:經理、業務、開發、測試、用家等等能作有效的溝通,作者認為適當用詞能打開溝通。在此相對應的用詞有:

  • Test First ==> Specifying collaboratively
  • Automated Tests ==> Automated Validation without changing requirement
  • Tests ==> Executable Specification
  • Regression Tests / Continuous Integration ==> Validating frequently

顯然易見,主要就是要去掉「測試」字眼,免得業務人員覺得那是技術東西,自己不應該參與。Specification by Example (SBE) 除了用詞不一樣,也提高了軟件開發這整件事的抽象層次,也是目的。本書也盡量不專注在工具的使用,而是分享各個團隊的經驗,看看 SBE 在各團隊中如何得到實作,並遇上甚麼困難。

若說 TDD 能夠使我們交付正確運行的軟件 (build the software right),SBE 就專注使我們正確地交付 (build the right software)。兩者都用自動化測試去加快回饋,使我們得以盡早知道錯在那裏,減低重工 (rework) 成本。SBE 是大廻圈,TDD 是細廻圈。

我最初看一些 BDD/ATDD 的例子時,得知這些工具通常都會繞過 UI 層,直接測服務層,這無疑對於開發很有用,因為 end-to-end 的測試很難,而且出事時不能確指問題所在。不過對於業務人員,就會有些疑問:我怎麼知道看到那個列表測試通過,就代表軟件運作正常?對他們來說,錄製一段測試腳本,看其在畫面快速地運行,似乎是更直觀,也更有信心。

然而 SBE 有很好的理由去減 UI 測試:因為業務邏輯的改變速度,通常不及技術層。新技術、新版 library、新式 UI 往往發展得很快,但業務邏輯相對卻很穩定。需要一組穩定的、不需花很大力氣維護的測試。這裏因為處理的層次不同,所以應該用不同的方法對應。這裏也暗藏了 separation of concern 的原則,需要將設計軟件成可分隔的部份,也許算是測試的兩個面向的有關設計一面。

然而這信心問題如何解決呢?工具無用,最緊要是溝通。SBE 就是要打開這個溝通的機會,拉眾人進來討論。當大家有了信任,也信賴測試的效用時,就能發揮 SBE 的最大效用。書中提到很多團隊都領悟到溝通這個道理。

SBE 的終極目標,是成為 living documentation,一份既可執行的 spec,也能通過例子細說系統運作的文件。作者在訪問眾多團隊後,覺得這應視為重點。看書中團隊的經歷,本來引入 BDD/ATDD 是為了改善軟件品質,跌跌碰碰下才知道將關係人拉入溝通才是最重要的,最終有 living documentation 的團隊,即使遇上重大的業務決策,因為文件既齊又可執行,很快就從中看到可以如何快速而又安全地作出改變。

稍為要評一下可能是因為多個譯者的關係,感覺翻譯有點不一致,有些詞語會多次括號介紹。在選用中文或英文用字時,也有點怪怪的感覺。我想看英文版應該會好得多。

回應

*