在快速變化的環境中，持續集成和測試將發揮什么作用?它是否總是能發揮應有的作用?
我們在一天內總會收到許多代碼修改請求，而且會在一天內做多次修改，也會在一天內多次部署代碼。在這種快速變化的環境中，真的不需要所謂的執行規范，因為我們可以用其他的反饋機制來替代BDD或執行規范。但是，這并不意味著執行規范、BDD、 Cucumber或類似的東西不重要，實際上還是要由具體環境而定的。
根本問題在于，為什么項目一開始就要編寫測試?我們之所以編寫測試，是因為我們相信持續集成。什么是持續集成呢?持續集成是一種反饋機制，它能夠說明我們正在做的事情正是業務所需要的，所以它是一個用戶需要的特性，而且它要求編寫的代碼不會破壞現有的其他特性。我們編寫測試來強化代碼和保證代碼不會出現問題，并且通過測試來獲得反饋。持續集成的關鍵是給處于特定開發周期里的開發人員提供反饋周期。最重要的就是反饋，而不是得到反饋的方式。所以，在一些變化速度不快的環境中，單元測試或 Cucumber測試(或其他測試框架)就是能夠提供這種反饋的機制。在我們現在所處的環境中，它的不同之處是最終用戶數量較少，所以我們獲得反饋的速度更快。在部署到生產環境之后，由于不用編寫測試就可以直接從用戶獲得反饋，所以可以更快更高效地獲得反饋。更快的反饋方式是，用戶直接面對面地告訴我們:“請幫我修改一下這個字體，請幫我修改一下這個單元格的背景顏色。”如果開發者可以直接獲得反饋，修改后直接推送到生產環境，這種速度會快很多，因為他們不需要花更多的時間去編寫測試和等待反饋。
我已經認識到這一點，但是許多公司和大多數產品并沒有采用這種方式。我認為，BDD能夠提供更多的執行規范。我認為它有很大價值，道理很簡單:當無法快速響應和靠近最終用戶時，我們需要使用其他交流方法獲取反饋，而 Cucumber這樣的BDD框架正好能發揮它們的作用運維人員和開發人員都可以使用 Cucumber等框架去編寫測試。
在我的上一家公司里，有幾位同事在 Norwegian National Dairy(家奶牛養殖公司)等公司的項目中使用了 Cucumber框架。他們的軟件確實很難測試，因為不同的奶牛有不同的飼養流程。軟件里有許多復雜的業務規則，而他們編寫的系統需要處理所有的業務規則。他們對一位年近60歲的養殖專家進行了培訓。她并不是程序員，但了解養殖技術。他們教她如何用 Cucumber描述軟件的工作方式，然后她就一直寫這方面的東西。在她寫出需求之后，開發人員就根據她描述的業務規則實現相應的特性。培訓過程很簡單，因為 Cucumber從一開始就是面向非程序員設計的。所以，我認為教會非技術人員編寫可執行規范的方法確實適合許多團隊使用。
Cucumber- Nagios的核心原理是用 Cucumber編寫Wweb應用的一些最終可接受測試，然后在生產系統(使用 Nagios)上運行這些測試，通過這種方式來測試系統是否符合要求。因為這些測試現在是真正運行在生產系統上，所以我們知道生產系統是正常的。此外，如果系統不正常那么測試會出錯并生成警報，告訴我們生產系統出現了什么問題。當然，這只是整個測試驅動基礎架構的一種模式。所以，我們改變了開發人員長期以來的工作方式，即編寫代碼和測試代碼。現在，他們可以用這些方法來測試和開發代碼，然后我們將它們應用到運維上。我們把基礎架構也視為代碼，可以編寫測試，描述基礎架構應該有的狀態，然后再修改網站建設的基礎架構，使這些測試能夠通過，這時就說明基礎架構是正常的。
本文地址：http://m.123beaconmarketing.com//article/4492.html
