參考官方文件
Chinese traditional (zh-TW)
Chinese traditional (zh-TW)
| English Keyword | Chinese traditional equivalent(s) |
|---|---|
feature | 功能 |
background | 背景 |
scenario | 場景劇本 |
scenarioOutline | 場景大綱劇本大綱 |
examples | 例子 |
given | *假如假設假定 |
when | *當 |
then | *那麼 |
and | *而且並且同時 |
but | *但是 |
功能 Feature
目的是提供軟體功能的高階描述，底下會有更多細節的不同場景(scenarios)
場景 Scenario
說明業務規則的具體步驟
遵從相同的模式
描述初始化脈絡(假如 Given 步驟)
描述事件(當 When 步驟)
描述預期結果(那麼 Then 步驟)
步驟 Steps
每一步驟都由假如、當、那麼、而且或是但是開始
Cucumber會按照你腳本撰寫的順序執行每一個步驟一次
當Cucumber嘗試執行步驟時，會尋找對應的步驟定義去執行
尋找步驟定義時不會考慮關鍵字，這表示你不能在假如、當、那麼、而且或是但是步驟中使用跟另外個一步驟一樣的描述
Cucumber認為以下的步驟是重複的:
假如我的帳戶有錢
那麼我的帳戶有錢
這也許看起來是一個限制，但他會迫使你提出不太模糊，更清晰的領域語言:
假如我的帳戶有430英鎊的餘額
那麼我的帳戶應該有430英鎊的餘額
假如 Given
假如 步驟用在描述系統初始的脈絡。
這通常是過去發生的事情。
當Cucumber執行 假如 步驟，它將配置系統處於定義好的狀態，例如建立和設定對象或增加資料到測試資料庫。
假如 步驟的目的是在使用者(或外部系統)開始與系統互動之前(在當步驟中)，將系統設定於已知的狀態。避免在假如中寫有關使用者互動的描述。如果你要建立使用者案例，假如是用來寫你的先決條件。
可以連續執行假如步驟(將第2個或其他的寫做而且或但是更有可讀性)
例如:
- 米奇跟米妮開始了一場比賽
- 已經登入
- 喬有42歐元的餘額
當 When
當步驟是用來描述事件或動作。這是一個可以與系統互動的人，也可以是由另一個系統觸發的事件。
強烈建議每個場景只有一個當步驟。如果你不得不增加更多個，通常表示你應該要將該場景分割為多個場景。
例子:
- 猜一個字
- 邀請朋友
- 提款
想像一下1922年
大多數軟體會執行人們可以手動執行的操作(只是效率不高)。
試圖突出一些例子，這些例子不對技術或使用者介面做出假設。想像一下1922年，當時沒有電腦。
實做細節應該要隱藏在步驟定義之中。
那麼 Then
那麼步驟是用來描述預期的輸出或結果。
那麼步驟的定義應該用在斷言，將實際結果(系統實際執行的結果)與預期結果(步驟說明系統應執行的操作)做比較。
結果應該在可觀察的輸出上。也就是說，系統中出現的東西(報告、使用者介面、訊息)，而不是深深地埋在系統內部行為(像是資料庫中的紀錄)。
例子:
- 看見猜的字是錯的
- 收到邀請
- 卡應該被吞下
儘管執行那麼步驟中查看資料庫的做法很誘人-抵制這種誘惑!
你應該只驗證使用者(或外部系統)可以觀察到的結果，而資料庫所做的改變通常不是。
而且 And、但是 But
如果你有連續的假如、當、那麼你可寫成:
例子:多個假如
假如一個件事情
假如其他事情
假如還有其他事情
當我睜開眼睛
那麼我應該看見東西
那麼我不應該看見其他的東西
或者，你過將連續的假如，當或是那麼替換為而且和但是來讓例子的結構更加流暢:
例子:多個假如
假如一個件事情
而且其他事情
而且還有其他事情
當我睜開眼睛
那麼我應該看見東西
但我不應該看見其他的東西
*
Gherkin也支援使用星號(*)代替任何步驟關鍵字。當某些步驟是事情列表時，這可能會有所幫助，因此你可以更像子彈點那樣表達它，否則而且...等的自然與言讀起來可能不太優雅。
例子:
場景: 全部完成
假如我出去逛街
而且我有雞蛋
而且我有牛奶
而且我有奶油
當我確認我的列表
那麼我什麼都不需要
可以表示為:
場景: 全部完成
假如我出去逛街
*我有雞蛋
*我有牛奶
*我有奶油
當我確認我的列表
那麼我什麼都不需要
背景 Background
有時候你會發現，自己在功能的所有場景中都有重複相同的假如步驟。
由於在每個情境下都需要重複執行此操作，因此表示情境描述這些步驟是不需要的;他們是附帶的細節。你可以透過將假如步驟分配到背景的部分裡。
背景以相同的段落位置放在第一個場景/例子之前。
例子:
功能:多網站支援
除了管理員之外，只有部落個的所有者可以發布文章，誰可 以發布到所有部落格。
背景:
假如一個名為"葛雷諾"的全球管理者
而且一個名為"葛雷諾的抗稅措施"部落格
而且一個名為"比爾醫生"的顧客
而且一個由比爾醫生擁有名為"昂貴療法"的部落格
場景:比爾醫生在自己的部落格上發表文章
假如我用比爾醫生的身份登入
當我嘗試發表文章到"昂貴療法"
那麼我應該看見"你的文章已發布"
場景:比爾醫生嘗試發表文章到別人的部落格但失敗了
假如我用比爾醫生的身份登入
當我嘗試發表文章到"葛雷諾的抗稅措施"
那麼我應該看見"嘿!這不是你的部落格!"
場景:葛雷諾發表文章到客戶的部落格
假如我用葛雷諾的身份登入
當我嘗試發表文章到"昂貴療法"
那麼我應該看見"你的文章已發布"
背景也支援規則級別，例如:
功能: 任務過期
讓使用者知道任務何時過期，就算使用者用的是該App的其他功能
規則:在當天首次使用時通知使用者有關過期任務的訊息
背景:
假如我有一個過期任務
例子:當天首次使用
假如我上次使用App是昨天
當我使用App
那麼我收到有關過期任務的通知
例子:今天已使用
假如我在今天稍早使用了App
當我使用App
那麼我沒有收到過期任務的通知
...
謹慎使用
每個功能或規則只能有一個背景步驟。如果你需要對不同場景使用不同的背景步驟，請考慮將你的場景拆解為更多規則或更多功能。
對於背景的不太明確的替代方法，請參考條件hooks。
使用背景的提示
- 不要使用背景來設置複雜的狀態，除非該狀態是客戶需要知道的。
- 例如，如果使用者與網站名稱對客戶來說無關緊要，請使用更高級別的步驟描述，像是假如我以網站擁有者的身份登入。
- 保持你的背景部份簡短
- 客戶在閱讀場景時實際上需要記住這些東西。假如背景長度超過四行，請考慮將一些不相關的細節移到更高級別的步驟中。
- 讓你的背景部分生動
- 使用色彩鮮豔的名稱，並嘗試講一個故事。人腦對故事的理解比對"使用者A"、"使用者B"、"網站1"的理解好。
- 保持場景簡短，不要太多
- 如果背景部分已經滑出螢幕之外，則讀者將不再具有所發生情況的完整描述。考慮使用更高級別的步驟，或拆分*.feature檔案。
場景大綱
場景大綱關鍵字可以用在多次執行相同的場景不同的參數狀況。
關鍵字場景模板跟場景大綱是同義字。
為了不同的參數複製貼上場景很快變得乏味且重複:
場景: 在12條中吃5條
假如我有12條小黃瓜
當我吃了5條小黃瓜
那麼我應該有7條小黃瓜
場景: 在20條中吃5條
假如我有20條小黃瓜
當我吃了5條小黃瓜
那麼我應該有15條小黃瓜
我們可以將這兩個相似的場景折疊成一個場景大綱
場景大綱: 吃
假如那裡有 <開始> 條小黃瓜
當我吃了<吃>條小黃瓜
那麼我應該有<剩下>條小黃瓜
例子:
| 開始 | 吃 | 剩下 |
| 12 | 5 | 7|
| 12 | 5 | 7|
| 20 | 5 | 15|
場景大綱必須包含例子(或場景)部分。其步驟被解釋為永遠不會直接執行的模板，場景大綱為例子中的每一行執行一次(不包含第一行標題)。
這些步驟使用 < > 分隔的參數可以參考例子列表中的標題。在嘗試將步驟與步驟搭配之前，Cucumber將用例子列表中的值替換這些參數。
你以可以在多行步驟參數中使用參數。
步驟參數
在某些情況下，你可能想將更多資料傳遞給一個步驟，而超出一行。因此Gherkin 提供文件字串和資料列表。
文件字串
文件字串便於將較多的文字傳遞給步驟定義。
文字應該被三個雙引號包起來的資料替換:
假如一個部落格發表Markdown 結構名為"隨機"的文章
"""
一些標題，恩?
=============
這裡是我部落格文章的第一段。
"""
在你的步驟定義中，不需要尋找文字去配對。它會自動傳遞給步驟定義中的最後一個參數。
開頭"""的縮排並不重要，儘管通常得做法是在一個封閉的步驟插入兩個空格。但是三個引號內的縮排非常重要。文件字串的每一行都將根據開頭的"""進行分隔。因此，將保留超出"""列的縮排。
資料列表
資料列表非常適合將參數列表傳給步驟定義:
假如存在以下使用者:
| 名字 | email | 推特 |
| Aslak | aslak@cucumber.io | @aslak_hellesoy |
| Julien | julien@cucumber.io | @jbpros |
| Matt | matt@cucumber.io | @mattwynne |
就像文件字串，資料列表將傳遞給步驟定義的最後一個參數。
Cucumber提供了豐富的API，可用於在步驟定義中操作列表請參考資料列表API。
留言
張貼留言
有什麼想法歡迎跟我們分享