將TDD應用於功能測試

Question

我們已經開發了一款產品，現在已經有2個月了，它的單元測試覆蓋率很高。我們大多數人都先寫測試，然後編寫代碼。這意味着我們可以信任我們的測試，因爲我們先使用紅色，後來綠色的方法。

迄今爲止，我們已經向用戶展示了我們的功能。但是，隨着我們開始涉及越來越多的要求，我們有必要使用功能測試來滿足這些要求。

目前我們沒有功能測試。

我們有一位處理要求的團隊成員，我相信他會成爲編寫功能測試的好人。但我擔心的是功能的開發和功能測試的寫作將不同步。也就是說，在功能完全實施之前，測試不一定要寫入。

我們是否應該有一個規則，此後功能測試纔會寫入功能？換句話說，先是紅色，後面是綠色。或者還有其他方法。

Answer 1

如果不適合你的話，你不應該將自己鎖定在模式中（例如，先是紅色，後面是綠色）。就你而言，在你進行功能測試之前，我已經看到了功能完整性的問題，因爲你已經有了很好的單元測試覆蓋。

但這只是我，我確定硬核TDD：ers會不同意。

Answer 2

您正在描述的方法稱爲行爲驅動開發（BDD）。本質上，它與功能測試的測試驅動開發類似。需求或行爲（或用例或場景，無論您在自己的商店中指定需求由您決定）都以功能測試的形式進行描述，包含入口和出口條件，然後重複使用TDD來實現行爲在你的系統中。

一個支持BDD的簡單（且重量輕）的開源框架稱爲FitNesse。這是一個用於捕獲需求的維基風格編輯器。在每個需求中，您都會包含一個示例請求和結果表，然後Fitnesse會自動調用服務併爲您進行測試。這不是那裏最好的工具，我認爲它不能很好地擴展，但它可以快速啓動。另一種工具（比FitNesse更好，或者我聽說過）是soapUI它更加完整，可以做一些事情，比如缺少服務，進行負載測試，組織測試等等。

TDD和BDD之間的一個區別是，在BDD中，根據行爲的性質，功能測試可能會或可能不會完全自動化。自動化程度越高越好，但有時更容易讓人類通過腳本來運行，或者眼睛看到一些結果。您需要用於BDD的測試環境也可能更加複雜，包含實際的數據庫和服務。雖然這意味着您可以以現實的方式對行爲進行全面測試，但這也意味着您必須擁有一個充滿應用程序所依賴資源的測試環境。這不是一件壞事，只是你的測試變得真實。