規格示例：如何管理低級別詳細信息

Question

我需要一個BDD/ATTD /規範專家的建議。 （對不起了很長的文章，我不知道如何表達的問題較少的話）

問題描述

我們一直都在一箇中等規模的項目約1年。 該團隊使用受驗測試驅動的基於流程的過程（以詳細測試用例的形式編寫）。

而現在，隨着需求的變化，我們開始遇到這些測試的可維護性問題。

1. 他們是（非常）硬盤讀取一個絕對不作爲產品 規格多日的要求結果
2. 稍有變化 重構的測試過於加上實施細則

我們怎麼看它解決

爲了解決我們要我們的測試轉化成可執行的規範問題。 所有的書/文章我讀過（例如，通過例如通過戈傑科·阿德齊奇規範）建議，我們不與低級別的詳細信息，告訴相當如何產品應當執行的，而不是什麼超載規格產品應該符合商業期望。

這似乎是合理的，因爲規格可能會更具可讀性和可維護性，並且反映了業務目標，而不是過分指定時的軟件設計。 但是，這些低級別的細節不能被丟棄 - 雖然它們並未被業務用戶明確地詢問，但它們仍然是可預期的。例如，如果用戶按下「處理按鈕」，則最好禁用並且「取消按鈕」被啓用，直到處理完成。像這樣的細節在規範中似乎是不必要的，但對於應用程序被客戶接受是必需的。

我們在每個級別使用（A）TDD，並且僅用於編寫代碼以進行測試。現在不用詳細的測試，我們會有更多的抽象可執行文件規範，而且根本不知道把低級細節放在哪裏。

問題

因此，能不能有人建議管理水平低的要求是不能去了說明書的好的做法呢？

Answer 1

我想描述的步驟爲When user presses 'Process button'絕對是告訴我們系統應該如何實現，而不是描述什麼產品應爲企業做的。我們從這一步中知道什麼？只有我們在UI上的某處有按鈕（不是鏈接，不是其他控件），其上有文字Process。沒有關於商業。更糟糕的是，它非常脆弱。如果您將按鈕的文本更改爲Start，則此步驟將無效。如果您更改控制類型，則相同。

點擊按鈕不是商業目標。那麼，如何描述業務目標呢？我認爲When user starts processing bills是很好的步驟定義。如果您更改UI，則此行爲將保持不變。它不再脆弱。只有步驟的實施纔會改變。