測試優先的原教旨主義就像禁欲教育:是一個不切實際的、無效的道德活動,讓人自我厭惡和羞恥。
剛開始時情況并非如此。當我第一次發現TDD,它就像一個禮貌的邀請,一個能夠更好地編寫軟件的世界。心靈上的促動使你去開始測試實踐。它開闊了我的眼界,經過良好測試的代碼庫,他帶來了軟件變革的信心。
測試優先是很好的自我訓練方式,它教我如何在更深層次上思考測試,除此之外也有些內容我很快就拋之腦后了。
然而,多年來,關于測試優先的言論聲音越來越大,而且常令人非常生氣,甚至是卑鄙。有時我被卷入原教旨主義的漩渦,之后就會因為沒有跟隨真正的福音而感覺不好。之后的幾周時間我盡量嘗試著測試優先。只有當它開始傷害我的設計時,我才再次停止它。
當我能夠堅持的文字字母教義,我會感覺這就是溜溜球循環的驕傲;當我沒有做到時,我感覺陷入絕望的崩潰。這感覺就像是跌落馬車一樣。有些事情需要保持沉默。當然不是在公共場合承認。在公共場合,我充其量只是提到不做測試優先,并在最壞的情況下繼續支持實踐“正確的方式”。但我現在后悔了。
也許使用測試先行這種違反直覺的方式來改變缺少自動化的回歸測試的行業現狀,是有必要的。也許這只是一個寓言,只是一個沒有文字描述準備的軟件編寫的日常運作。無論他以什么形式開始,很快就墮落了。被人用做錘子用來
打倒不同意見,告訴他們是不專業的,并不適合編寫軟件。這是一個試金石。
足夠了。沒有更多了。我的名字是大衛,我不奉行測試有限。我拒絕為它的任何事道歉,更別說隱藏它了。我很感激TDD開拓了我自動化回歸測試的眼界,但我早已跟從設計教條了。
我建議你認真看看何為這種方法做系統設計的完整性。如果你愿意認真考慮它的可能性,這不是一個不合格的好,就像紅色藥片。你可能不喜歡你所看到的東西。
因此,我們該何去何從?
第一步是要承認一個問題。我認為我們現在已經看到了。第二步是從單位到系統重新平衡測試光譜。當前狂熱的TDD經驗導致主要集中在單元測試,因為這些都是測試驅動代碼設計的能力(原測試優先的理由)。
我不認為這是個很健康的想法。測試優先單元會導致過度復雜的網絡中介對象,為了避免做任何“慢”的事情,就會導致間接行。就像鏈接數據庫,或文件IO?;蛘咄ㄟ^瀏覽器來測試整個系統。生成了一些真正可怕的怪物的建筑。如果服務對象是茂密的叢林,這種命令模式的話就更糟了。
我很少進行那些所有依賴項都被模擬,成千上萬的測試可以在幾秒鐘內完成的傳統意義上單元測試,。我直接測試Rails的Active record,讓它們直接訪問數據庫,然后在其上部防止一些控制器的測試,但我寧愿使用Capybara 更高水平的系統測試取代它們。
我認為這就是我們前進的方向。不要太過重視單元測試,因為我們不再做測試優先設計實踐,更強調的是,緩慢、系統測試。(順便說一句,由于先進的并行化和云基礎設施,我們不再需要如此緩慢地運行)。
Rails可以幫助這種轉變。今天我們除了鼓勵全系統測試外什么都不做。在堆棧里,并沒有默認的答案。這是一個需要我們修復的錯誤。但你不必等到發生時才做。今天讓 Capybara運行,你會有一個美好的明天。
但是,請首先深呼吸。我們現在正趕一些神圣的牛去屠宰。這是痛苦的和血腥的。TDD一直如此成功以致讓很多程序員的身份交織在一起。TDD不僅僅是他們做什么,還要搞清楚他們是誰。我們前面,有一些嚴重的思想阻止我們擺脫困境,這將是需要一些時間的。
最糟糕的事情是,我們能做的只是沖到另一個測試的宗教。我只可以想象 “只測試系統”的金牛犢!現在,請不要去那里。
是的,于我而言,測試優先已死。但是,與其說它是跳舞的墳墓,我寧愿紀念它所作出的貢獻,而不是停留在悲劇哪里。這是我們歷史上一個重要的階段,但現在是時候繼續前進了。
原文轉自:http://www.testwo.com/article/140