我正在使用Specflow（黃瓜）使用C＃開發CDD的BDD測試自動化解決方案，並將測試編寫為純文本Gherkins。我目前正在編寫一個回歸測試套件。
當斷言用戶UI事務已成功更新時，我可以想到幾種方法：
使用步驟/步驟定義：將數據輸入到網頁中，然後單擊"保存"按鈕，然後斷言成功對話框。然後導航到另一個網頁或可能是多個其他網頁的數據將被更改的地方，並斷言數據已在必要字段中正確更新。
使用步驟/步驟定義：將數據輸入到網頁中，然後單擊"保存"，斷言顯示成功對話框。然後編寫調用API類以檢索存儲（獲取）的數據的步驟/步驟定義，然後斷言存儲到數據庫的所有數據都是正確的。
第一個選項看起來像功能測試的真實表示，用戶將如何執行它，並且還保證數據可以正確顯示給用戶。當我編寫Gherkin步驟時的第二個選項"然後API調用將返回以下數據："-似乎不適合商業可讀格式？還有可能仍然無法在UI上正確顯示數據。這將需要編寫許多API類。
作為軟件工程方法，第二種選擇是否是推薦方法？
In this case , The only need for testing the backend database is when you doubt whether the browser is actually getting the data from the database or is it simple caching it in cache or browser local storage.
So, if you want to ensure that's not what is happening, then use driver.quit() and open a new driver instance. This will be a new instance with all the local storage, cache etc are cleared. So you can be pretty sure that the data is indeed from backend and not a browser cache.
But if you still feel pessimistic that the site is not calling actual database and then, write a function to validate the backend and you can mask the API call in the spec flow step.
Eg:
Given("User sends data")
public void step(){
{
senddata(a)
verifydata(a) // step to verify api
}
In BDD you don't have to show the implementation
It all depends on the logic you intend on testing, and when the test fails, how large an area of the application you'll need to investigate.
A full end-to-end test verifies data on screen. Doing this in BDD certainly replicates that test, but the behavior is what BDD is about. What behavior are you testing? How many reasons does your test have to fail?
If you replicate the full end-to-end test in BDD, and it fails because something does not appear on screen, you need to investigate quite a bit of code for the failure. If the test creates some data via the user interface, then verifies that data appears on screen on a different page, then what part failed? Did the "create data" page fail? Did the "view data" page fail? Did the call to a web API fail? Did the web API itself fail?
It becomes frustrating to debug this failing test, because you have so much to look at. Despite the frustrations a full end-to-end test is useful. It ensures all the parts work together. You do not necessarily need to add data to the system using the UI. It is appropriate to make direct database calls or web API calls from your Given steps. This is nice, because the tests will likely run faster, and the tests are less likely to fail on a Given step. Ideally you want a test to fail on a Then or When.
Scenario: ...
Given thing A exists # Calls database
And another thing has been done # Calls web API
When I do the thing # Selenium interacts with the browser
Then something should change # Selenium verifies info on screen
Full end-to-end tests should be much fewer in number than the more fine grained tests asserting certain variations of behavior. Those require their own tests.
If you intend on testing the UI layer, then a full end-to-end test is appropriate. If you want to test the APIs themselves, I would not involve the user interface at all. Have your cucumber steps call the APIs directly.