小黃瓜描述測試或功能？

這是我碰到和我的同事一個有趣的話題，我有對此事的不同看法。如果你的小黃瓜準確地描述了測試的內容，或者只顯示你在測試中試圖達到的商業邏輯。小黃瓜描述測試或功能？

我一直在工作中遇到的最大例子是，如果你有權訪問項目A，那麼你應該能夠訪問A.我們可以有20種不同類型的用戶訪問A，所以我們只選擇1（保持我們的測試套件運行40小時）。那麼哪個更好？

甲

Scenario: A user with access to item A can access A 
Given I am a type 4 user with access to item A 
When I try to access A 
Then I am granted access to A

或B

Scenario: A user with access to item A can access A 
Given I am a user with access to item A 
When I try to access A 
Then I am granted access to A

通知在給定的發言（類型4用戶）

在我們要使用類型的步驟定義授予的差4用戶進行我們的測試，但測試不是特定於類型4用戶的。任何具有項目A的用戶都將參與此測試，因爲我們需要用戶類型才能登錄，所以我們只使用類型4用戶。

所以介紹測試是做什麼

而B描述（訪問項目A只是一個用戶）訪問項目A所需的功能（與訪問項目A型4用戶身份登錄）

你問之前，我們如何決定誰有權訪問項目A是SQL調用數據庫中尋找鏈接到用戶的特定項目。

來源

2013-03-12 Matt Westlake

對於正在測試的業務邏輯的黃瓜試驗 - 作爲驗收試驗 - 不HTE具體的實施細則。所以你應該做第二個不是第一個。如果要運行X型，Y型和邊緣案例的測試，則您的請求規範或集成測試可以更多地與特定關聯。

我覺得人能想到這一點 - 它不是一個艱難快速的規則 - 就像這樣：

單元測試在同一時間以隔離方法和測試的一件事。模擬&存根其他一切隔離什麼被測試。

集成測試，以測試事物如何互動起來，以測試你的籌碼的較大部分，包括多個物體之間的相互作用。有人會爭辯說，你在這裏測試了所有的湯，但我認爲在一個大的複雜應用程序中有一個地方可以測試大量的片段，同時還不能測試完整的請求週期。

請求規格 - 有時是簡單的應用程序，這些是幾乎一樣的集成測試，在其他情況下，我會做集成測試的一切，除了請求堆棧和專門分離出來我的要求的規格。意見會有所不同。

驗收試驗 - 這是你與你的問題坐 - 在測試被寫在普通的商業語言，避免了功能定義中的技術實現細節。

不管怎樣，即使你忽略的測試堆棧的其他思想，在具體的問題你問隨時隨地B.

來源

2013-03-26 02:02:21

我想說選項B是更好的。「類型4用戶」聽起來像是一個實現細節。

但是，如果要求所有用戶類型都有訪問權限，那麼它也應該成爲規範的一部分。在這種情況下，測試應該指定並測試所有的用戶類型。

來源

2013-03-26 16:27:11 andrewtatham

我會說B更好。對於「類型4用戶」你可以把它變成一個背景的一部分：

Backgound : User is logged in 
Given "Type 4 user" is logged in

使用4類用戶的佔位符將其置於「」這樣你就可以重複使用登錄其他用戶的步驟定義有權訪問項目A

來源

2013-04-11 06:45:44 fancypi

更爲自然的方法是描述用戶：管理員登錄或新用戶登錄。 – Chriseyre2000 2013-08-27 13:01:27

小黃瓜描述測試或功能？

回答

相關問題