shell Ubuntu Python nginx mysql linux 微软 开源 程序员 java centos google Firefox php apache wordpress Android Windows 编程 云计算

測試驅動開發與行為驅動開發中的測試先行方法

Gil Zilberfeld將在 Agile Practitioners會議上舉辦小型研討會,討論測試先行(test first)方法,測試驅動開發(TDD)和行為驅動開發(BDD)的基礎。

Test-First是一個很優秀的工具。它能促進團隊內更好的理解力和生產力。其結果是高質量的代碼——無論是早期成功發現 bug還是正確實現特性方面。

Agile Practitioners 2016會議將於1月26-27日在以色列特拉維夫舉行,InfoQ將會覆蓋本次會議的新聞,Q&as和文章。

(……)今年我們的主題是親身實踐敏捷。我們知道沒有老師能夠傳授親身體驗,因此我們舉辦了很多研討會和實用講座,會議參加者可以親身體驗、聽到和看到敏捷活動是如何在許多成功企業內實施的。

InfoQ采訪了 Zilberfeld,關於測試先行方法的優勢,測試驅動開發和行為驅動開發概念,團隊使用 BDD和 TDD的實例,以及如何在不編寫任何代碼的情況下探索 BDD和 TDD。

InfoQ:“測試先行”方法的優勢是什麽?

Zilberfeld:測試驅動開發是從90年代末的極限編程從業者開始的。但事實上,人們在編寫代碼的數十年前已經開始編寫測試了。

其理念是這樣的:當程序員編寫代碼時,他們通常在代碼中解決復雜問題。但是,這種方式常常使得結果同樣復雜,並且含有遠遠超過實際需要解決的問題(假設重要的東西已經被編碼)。

這意味著需要測試更多的代碼。測試有時需要改變“已經工作”的代碼,這會引入風險。最終導致要麽根本沒有進行測試,因為沒有時間測試,或者是次優的測試,因為無法覆蓋我們想要覆蓋的範圍。

測試先行定義了工作需求。因為我們有測試形式的定義,它定義了為了解決具體問題我們需要編寫什麽樣的代碼。僅僅通過運行測試就可以非常簡單地知道我們是否有可工作的功能。

這種方式會擴大測試覆蓋率,因為測試成為優先開發活動,而不會被迫推到最後。

另外,編寫這些測試和制定場景的時候,我們會更深入地探索問題空間,因為會出現許多問題。而在事後測試(test after)中,有時不會發生這些討論,開發人員以他們的思維編碼,而不是以解決方案的需求編碼。

InfoQ:你能簡單介紹一下行為驅動開發(BDD)和測試驅動開發(TDD)的概念嗎?

Zilberfeld:在 TDD和 BDD中,你先將問題分解成多個情境,也就是例子。我們的頭腦更容易專註小情境,而不善於解決大的、復雜的問題。

然後開始著名的紅-綠-重構循環,就像這樣:

編寫一個失敗的情境。失敗是因為編譯或者因為代碼不存在。無論如何,該測試是代碼如何被外部模塊使用的案例。
努力讓測試通過。重點是可工作的功能而不是形式,也就是編寫最小的實現,讓它通過測試。更進一步,它應該通過迄今為止我們編寫的整個測試套件。
改進代碼。現在一切都是綠色的,使用測試安全網我們可以重寫代碼。如果我們破壞了什麽,我們會立即知道。
將問題分解成更小的部分,然後以增量的形式開發需要的代碼,並且在流程中加入急需的剎車。這有助於我們思考我們遺漏的情境,而不是“我們知道解決方案是什麽樣子”。

BDD開始於2000年代中期,更進一步地將 TDD推向產品空間。通過使用產品用途案例,我們可以僅僅開發情境所需的代碼。我們可以專註對業務重要的情境。然後可以使用 TDD編寫實際代碼。

BDD最大的優勢是溝通。如果你將“三個同伴”——業務分析師、開發人員和測試人員——集中到一個房間,討論我們希望看到的行為案例,那麽在編寫代碼之前,我們將會得到最好的提出和解決問題的觀點。

而這就是 BDD——討論商定的行為案例。這些案例可以寫成自動化測試(但這不是要求),然後編碼使測試通過,最後重構代碼。

顯然,BDD情境的詳細程度比更精細的 TDD測試還要寬泛。盡管我發現在某些方面它們是相互關聯的,但是在 TDD和 BDD情境中編寫測試還是需要不同的技能。

InfoQ:你有與合作團隊使用 BDD和 TDD的案例嗎?

Zilberfeld:在 BDD中,由誰編寫情境是有區別的,但是我合作的大多數團隊中,都是測試人員編寫情境。這些案例的討論通常在編寫代碼之前。測試人員和開發人員並行工作——測試人員專註高水平的自動化測試,開發人員專註代碼和單元測試(測試優先與否)。一旦完成就會對情境進行評審。然後在某個時候對開發和測試進行集成,以確保測試通過。

BDD和 TDD在叠代中非常“敏捷”,這使得情境“完成”與否非常的明顯。BDD情境要麽“符合”叠代,要麽就是故事過於冗長。

在實現上 TDD稍有不同。培訓之後,開發人員會對等待他們的代碼妥協。通常這些都是遺留代碼,這與幹凈的測試先行代碼不同。

我常開玩笑說 TDD中最後一個 D是紀律。因為它對測試先行的實現最重要。它與我們被教導的不同也更難,因此在看到價值之前我們需要團隊的支持。這就是為什麽大部分團隊最終不做 TDD,勉強接受事後測試的緣故。

熬過困難的前期之後,開始清理自己的代碼,添加更多的覆蓋率。代碼變得更加容易維護。並且從社會角度來看,新加入團隊的開發人員會帶著“這就是我們的工作方式”理念加入 TDD。這是一個正面的反饋循環。

InfoQ:你能給 InfoQ讀者提前透露一下 Agile Practitioners會議上研討會的內容嗎?以及向參會者展示如何在不編寫任何代碼的情況下探索 BDD和 TDD?

Zilberfeld:這次研討會背後還有一個故事。幾年前,我打算在比利時 Testing Days會議上舉辦“TDD a spaceship”研討會(我打算三月在荷蘭的 Agile Testing Days會議上舉辦)。它是為開發人員設計的,但是參與者都是測試人員,擁有極少的編碼經驗。因此研討會變成解釋測試先行的理念,並且是在沒有實際編碼的情況下。很自然地,我被吸引到星球大戰的例子,我們交談、做課堂筆記,並討論了驗收標準,以及如何知道故事已經完成。

那次研討會之後,我考慮如何以一種經驗的方式實現它。碰巧,我被介紹給GIF制作軟件工具,突然之間我們有了能夠幫助的工具。這是一個創建型工具,人們可以提前寫電影“腳本”,構建並運行,並能夠立即獲得反饋。

很棒的是我們可以應用敏捷開發原則和經驗。因為你所想象的電影樣式跟實際結果總是會有出入,所以我們構建了一個新的版本。

另一個案例是處理遺留代碼。其中一個練習是在電影中更換演員,但是因為電影已經編輯,因此我們只能在開頭或者結尾添加場景。鑒於需求與代碼不能分開考慮,如何更改需求與已經構建完成的代碼之間的沖突這一理念就非常有啟發性。

InfoQ:你同時還是agile practitioners會議的組織者之一,你能提前透露一下會議議程嗎?

Zilberfeld:這是我們第五年舉辦該會議,自創立以來無論是規模還是質量都得到了提升。它被列為以色列最好的敏捷會議是因為:

我們圍繞“親身實踐”主題會議。我們將有全天的專題報告、小型研討會,甚至演講都具有實際用途。我們旨在讓人們親身體驗,然後回歸工作,開始實施他們學到的內容。

我們為不同類型的參與者準備了內容——Scrum Master,測試人員,開發人員,產品經理,團隊領袖等任何你能夠想到的。但是,該會議不僅僅是拓寬你的角色知識。它是以一種“親身實踐”的方式讓你學習別人如何做的。

延伸阅读

    评论