TDD：「僅測試」方法

Question

在此尋找一些實用建議以及人們在類似情況下遇到的任何體驗。

我們使用BDD/TDD sytle方法來構建我們的軟件（相當大/複雜的應用程序）最終結果是從業務需求導出的行爲規範（Given/When/Then style），反映這些行爲的單元測試和反映測試要求的代碼。但是，最近我們的測試部門已經開始運行集成測試，並且可以理解，他們想要使用我們（已經通過）的​​業務邏輯代碼來設置和拆除測試狀態（而不是直接與數據庫打交道），作爲他們主要關注通過應用程序的UI進行測試，並且不希望花費整天的時間來討論數據庫。

問題是，一些實體存儲庫沒有刪除方法，因爲目前還沒有業務需求。許多已經存檔/恢復/備份等（並且可能在待辦事項上有待刪除）。

所以現在我們有一個測試部門。要求刪除（但與商業用戶故事衝突）

所以....我的問題是...如果我要添加方法專門爲測試部門...處理的最佳方式是什麼這些。我知道這在「TDD烏托邦」中被普遍認爲是不正確的做法，但實際上，您是如何處理這種衝突的？

的第一個想法我有或者是使用命名...

void TestOnly_Delete(Guid id){} 

... ...屬性

[TestOnly] 
void Delete(Guid id){} 

...或編譯器指令...

#if TESTBUILD 
void Delete(Guid id){} 
#endif 

所以至少開發人員可以知道不要調用TestOnly方法，並且最大程度上不會在生產版本中部署測試方法。

...或只是欺騙並添加一個用戶故事來管理它的方式;-)

任何經驗或建議，衷心感謝？

在此先感謝。

Answer 1

您首先應該關注的是確實增加了這個功能增強或者惡化了當前的API嗎？ TDD中的一個典型場景是，一個類成員（最初）只是爲了可測試性原因而需要，但它符合所有正常的API設計準則，所以它不會造成任何傷害（並且通常隨後會成爲生產代碼中有價值的補充以及）。

當這是真的，那麼通過一切手段只需添加它如果你可以這樣做很容易。

然而，有時候情況恰恰相反。在這種情況下，您必須抵制添加成員的衝動。但是，通常您可以按照Open/Closed Principle的說法打開您的API，以便其他人可以添加所需的功能。 Testability is really just another word for the Open/Closed Principle。

就你而言，最簡單的解決方案可能僅僅是確保所討論的類未被封裝，然後要求測試部門從這些類派生並自行實現這些功能。如果他們沒有這種能力，那麼你可以爲他們做，而仍然保持子類只進行測試。

Answer 2

在我的代碼，我創建一個子類：例如，如果我有一個DataLayer類具有所有的公共方法來訪問數據層，那麼我會用Test_DataLayer子類，它繼承自DataLayer和方法，它的子類它進一步實現了你可能想要的其他方法，如Delete，其實現可以訪問基類的內部或受保護的方法。

Answer 3

我通常最終得到一個「只測試」的項目/庫，它包含我測試所需的任何模擬/輔助類。在這個模擬庫中添加必要的類/方法（不包括在生產代碼中）看起來很適合這種需求。如果你還沒有這樣一個庫，並且不想創建一個庫，那麼我會標記 - 如果可能的話 - 這些方法是內部的，只能將它們暴露給測試框架。您不指定平臺，但我知道這對於C＃/ .NET是可能的，我經常使用此功能爲我的測試提供訪問庫之外不可用的方法的權限。

另一方面，我會說測試人員與實際客戶一樣，是您需求分析的一部分。就像我們有一些純粹滿足我們開發需求的要求一樣，我們也有一些測試要求。正如你所發現的，訣竅就是要儘可能地滿足利益相關者需要的全部的開發代碼。當需求衝突時，我們嘗試儘可能使用最佳折中方案。國際海事組織（IMO）允許從測試專用庫中刪除與客戶對數據安全（不刪除）需求的合理妥協。

Answer 4

這是一個有趣的問題。我有一些想法，但不知道它是否會成爲你的問題的答案。

我將親自創建一個繼承自您已經擁有的實體的顯式接口集合，例如IIntTest_Customer：ICustomer，並在那裏定義刪除方法。如果可能的話，試圖將所有這些接口放在單獨的項目中，這樣開發人員甚至不會從通常的項目中引用它，並避免意外使用它們。然後測試部門將使用此特定的內部測試接口進行測試。

要做到這一點，你也許不得不重構你當前的代碼，改變實體，實現這些內部測試接口來代替，而與繼承層次結構的所有現有的代碼應該仍然工作是指基本接口。

Answer 5

我永遠不會將刪除或其他清理方法添加到我的代碼中來支持自動化測試。

有很多選擇，從智能事務管理到數據庫自動恢復。