cucumber是ruby世界的bdd架構，開發人員主要與兩類檔案打交到，feature檔案和相應的step檔案。feature檔案是以feature為字尾名的檔案，以given-when-then的方式描述了系統的場景(scenarios)行為；step檔案為普通的ruby檔案，feature檔案中的每個given/when/then步驟在step檔案中都有對應的ruby執行代碼，兩類檔案通過正規表達式相關聯。筆者在用cucumber+watir做回歸測試時對cucumber工程的目錄結構執行過程進行了研究。
安裝好cucumber後，如果在終端直接執行cucumber指令，得到以下輸出：
輸出結果表明：cucumber期待目前目錄下存在名為features的子目錄。建好features檔案夾後，重新執行cucumber指令，輸出如下：
cucumber運作成功，但由于features檔案夾下沒有任何内容，故得到上述輸出結果。
網上大多數關于cucumber的教程都建議采用以下目錄結構，所有的檔案（夾）都位于features檔案夾下。
feature檔案（如test.feature）直接位于features檔案夾下，可以為每個應用場景建立一個feature檔案；與feature檔案對應的step檔案（如test.rb）位于step_definitions子檔案夾下；同時，存在support子檔案夾，其下的env.rb檔案為環境配置檔案。在這樣的目錄結構條件下執行cucumber指令，會首先執行env.rb做前期準備工作，比如可以用watir建立浏覽器視窗，然後cucumber将test.rb檔案讀入記憶體，最後執行test.feature檔案，當遇到given/when/then步驟時，cucumber将在test.rb中搜尋是否有相應的step，如果有，則執行相應的ruby代碼。
這樣的目錄結構隻是推薦的目錄結構，筆者通過反複的試驗得出了以下結論：對于cucumber而言，除了頂層的features檔案夾是強制性的之外，其它目錄結構都不是強制性的，cucumber将對features檔案夾下的所有内容進行扁平化（flatten）處理和首字母排序。具體來說，cucumber在運作時，首先将遞歸的執行features檔案夾下的所有ruby檔案(其中則包括step檔案)，然後通過相同的方式執行feature檔案。但是，如果features檔案夾下存在support子檔案夾，并且support下有名為env.rb的檔案，cucumber将首先執行該檔案，然後執行support下的其它檔案，再遞歸執行featues下的其它檔案。
比如有如下cucumber目錄結構：
為了友善記錄cucumber運作時的檔案執行順序，在features檔案夾下的所有ruby檔案中加上以下代碼：
puts file.basename(__file__)
此行代碼的作用是在一個ruby檔案執行時輸出該檔案的名字，此時執行cucumber指令，得到以下輸出（部分）結果：
上圖即為ruby檔案的執行順序，可以看出，support檔案夾下env.rb檔案首先被執行，其次按照字母排序執行c.rb和d.rb；接下來，cucumber将features檔案夾下的所用檔案（夾）扁平化，并按字母順序排序，進而先執行a.rb和b.rb，而由于other檔案夾排在step_definitions檔案夾的前面，是以先執行other檔案夾下的ruby檔案（也是按字母順序執行：先f.rb，然後g.rb），最後執行step_definitions下的e.rb。
當執行完所有ruby檔案後，cucumber開始依次讀取feature檔案，執行順序也和前述一樣，即: a.feature --> b.feature --> c.feature
筆者還發現，這些ruby檔案甚至可以位于features檔案夾之外的任何地方，隻是需要在位于features檔案夾之内的ruby檔案中require一下，比如在env.rb中。
最新内容請見作者的github頁：http://qaseven.github.io/