1000
《Cucumber：行為驅動開發指南》——第6章 Cucumber常見問題及解決之道 6.1感受痛苦
本節書摘來自異步社區《Cucumber：行為驅動開發指南》一書中的第6章，第6.1節，作者：【英】Matt Wynne , 【挪】Aslak Hellesy著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看
第6章 Cucumber常見問題及解決之道
如果團隊是第一次用Cucumber，用不了多久你就會注意到自己寫的代碼bug比以前少了。你發現自己可以勇敢地重構那些以前碰都不敢碰的代碼。看到自己的第一個場景通過時的那種喜悅，鼓舞著你不斷添加一項又一項特性。
然而，一段時間後，事情開始變味了。突然間你發現測試運行的時間實在太長；或者你開始注意到有幾個場景會隨機地失敗，而且通常是在緊張的工期已經臨近的時候；也可能不懂技術的利益相關人對這種開發過程興趣漸失，隻剩下開發人員還在閱讀那些特性。人們甚至開始問這樣的問題：
Cucumber是不是妨礙了我們的工作？
好消息是，這些問題都是有辦法解決的。我們在教練和顧問谘詢工作中曾見過各種各樣的團隊在學習使用Cucumber時遭遇各式各樣的問題。在本章中，我們將描述曾經見過的最常見的問題。我們會幫你理解這些問題的根源，給出應對它們的建議，或者，更理想一點兒，從一開始就避免它們。本章沒有太多代碼，但有大量有用的建議。
我們首先從問題入手，描述你的團隊可能經曆的4種不同症狀，然後我們會深入分析這些問題背後的原因，最後考察解決的方法。到本章結束時，你應該會對如何幫助團隊從長遠角度成功運用Cucumber持有更大的信心。
6.1 感受痛苦
我們從Cucumber出現問題時團隊可能感受到的痛苦中找出了主要的4種類型。看看其中有沒有你熟悉的。
下麵我們仔細看看上表中所示的每一種症狀。
6.1.1 閃爍的場景
一個場景，同樣的源代碼同樣的環境，昨天還能通過，今天卻失敗了，我們將這種情形稱為閃爍的場景。下麵是我們對閃爍的場景的定義。
閃爍的場景
閃爍的場景偶爾失敗，隨機失敗。同一個場景在相同環境的同一套代碼庫上運行，大多數時候能通過，有時卻失敗。這些似乎難以控製的失敗使團隊對測試、代碼和自身都失去了信心。
閃爍的場景最讓人討厭的一點是：一旦你嚐試重現它以便修複時，它反而不再失敗了。修複閃爍的場景是最困難的任務之一，也是最重要的任務之一。一組自動測試套件要想有用，團隊必須完全信任它。如果連單個測試都在破壞這種信任，那就會腐蝕團隊中各個成員對整個測試套件的信任感。
為修複閃爍的場景，你必須研究代碼，努力搞清楚它為什麼會發生。這是一種科學過程：對失敗原因做出一種假設，設計一個實驗來證實或證偽這一假設，然後執行實驗看自己是否正確。你可能需要多次重複這一循環才能找到問題的答案，如果閃爍的場景總是間歇地失敗，執行一個實驗可能需要好幾天。如果想法兒用光了，寧可考慮將整個測試刪除，也不要由著它自行選擇失敗的時間再回來折騰你。
6.1.2 脆弱的特性
你感覺測試套件讓你幾乎無法寫代碼，因為總會有明顯不相關的測試亳無理由地失敗，我們將這種情況稱為脆弱的特性。下麵是我們對脆弱的特性的定義。
脆弱的特性
脆弱的特性極易被破壞。特性脆弱時，在測試套件或主代碼庫的某個部分做些必要的修改會破壞明顯不相關的場景。
遇到脆弱的場景時，通常你是在做其他事情的時候。你被不期而至的失敗中斷了，隻好趕緊花時間去修複這意料之外的測試失敗。運氣不好的日子裏，這種情況會多次發生，害你深陷其中而遲遲不能自拔。脆弱的特性具有自我實現性：當開發人員察覺到自己的測試脆弱不堪時，他們常常就更沒有勇氣重構或清理測試代碼，相反他們會盡量快進快出，以求早一點遠離是非之地，於是測試和產品代碼便越來越難維護了。
6.1.3 緩慢的特性
每次往測試套件中添加一個新的場景，便在測試運行的總體時間中增加了幾秒。對一個用戶不斷要求新特性的成功應用來說，測試運行的時間隻會變得越來越長。長時間的測試正慢慢向你靠近：一開始5分鍾已經夠讓人難耐了；之後，15分鍾，雖然糟糕，但你已經習慣了在它運行時去喝杯咖啡；用不了多久，等你喝完咖啡回來它依然沒有結束，15分鍾變成了25分鍾；然後在不知不覺中，你的特性已經需要運行一小時甚至更長時間了。
新的場景一旦通過，繼續運行它的主要原因就是獲得反饋：如果你不小心破壞了它所檢查的功能，你希望場景可以給出警告。可隨著測試運行的時間越來越長，這種反饋的價值也就減少了。項目構建太慢時，開發人員在提交代碼前便不再運行全部測試，轉而依靠持續集成服務器來提供反饋。如果多名開發人員同時這麼做，他們所做的全部修改能集成到一起的概率也就不敢指望了，失敗的構建於是就成了家常便飯。
測試運行時間長還意味著人們不敢動手對Cucumber測試做重構或其他常規維護。如果某個步驟定義在340個場景中使用，重構其代碼是駭人的，因為你需要運行全部340個場景才能確切地知道自己的改動有沒有破壞了什麼。
6.1.4 厭倦的利益相關人
有的團隊嚐試使用Cucumber，最終卻隻把它當做了測試腳本的自動化工具，這樣的團隊中，最常聽到的一句抱怨就是“利益相關人不願閱讀我們寫的特性”。但也有許多團隊證實Cucumber確實能帶來改觀，有助於開發團隊更加有效地同業務利益相關人協作。這兩種不同的體驗差別源自哪裏呢？
答案的一部分在於要從一開始就同業務利益相關人建立正確的協作關係。如果他們覺得自己太忙，沒時間幫你準確理解他們想要的東西，那麼你麵對的是一個更深層的團隊問題，Cucumber愛莫能助。但另一方麵，許多團隊開始時倒是有熱心主動的利益相關人，可團隊卻浪費了Cucumber帶來的建立這種協作關係的機會。如果測試人員或開發人員獨自編寫特性，他們就難免使用技術術語，這樣利益相關人在閱讀的時候會覺得自己被邊緣化了。這會變成惡性循環：利益相關人本來可以幫助你使用對他們有意義的語言編寫特性，但隨著興趣漸失，他們花在這上麵的時間會越來越少。不知不覺中，特性就淪為純粹的測試工具了。
團隊中一旦發現這類症狀，就需要知道如何處理。這正是調查工作背後存在的問題並考慮應對措施的時機。
最後更新：2017-06-06 07:33:34