我從 TDD 和 JUnit 開始。在查看教程和文檔后，我有一些問題，如果我能得到一些最佳實踐反饋，我會很高興。A）我看到的所有示例都是針對具有某種語義/邏輯的方法。輸入->邏輯->輸出例如 2 個數字 -> 添加它們 -> 結果由于輸入到輸出的轉換，測試用例檢查邏輯。我明白這一點，它很好。如果沒有這樣的輸入（或者對外部結果有很大的依賴）怎么辦？例如String getName (int id)
{
// read the name of a staffmember out of the DB and return it
}我沒有看到可以在編譯/部署時檢查上下文無關的真正邏輯。什么斷言是有意義的，或者是一個沒有測試是公平的樣本？我認為只有對上下文獨立輸入的測試才有意義。外部數據庫或網絡請求的結果不是（我認為 - 你同意嗎？）。B）你們認為“方法存在”與“帶有測試用例的方法”的比率是多少？當然這取決于項目或主題，但我會對一些數字感興趣。
3 回答
米琪卡哇伊
TA貢獻1998條經驗 獲得超6個贊
正如 deHaar 在他的評論中指出的那樣，您想要涵蓋許多邊緣情況。在測試數據庫時，可以執行以下操作：
您模擬數據庫（在您的存儲庫中的 Spring 項目中），并將其配置為返回/拋出。然后在您的測試中，您測試以下內容：
givenNoCustomerInDB_thenNotFoundExceptionThrownIsWrappedToXXX(). 在這里，您將測試調用數據庫的服務方法是否捕獲異常并相應地包裝它。對于這種方法，您可能需要查找 Mockito，它是 Java 的“事實上的”模擬框架。另一種選擇是在進行測試時使用內存數據庫（例如 H2）。
要記住的一件事：您有責任確保模擬（或 H2）表現得像您的真實數據庫。@Kraylog 建議將適配器寫入 IO 設備的集成測試，以及確保模擬行為相同的合同測試。
蝴蝶刀刀
TA貢獻1801條經驗 獲得超8個贊
首先，雖然大多數函數都可以進行測試，但并非所有函數都需要直接測試。通過調用代碼的測試可以更好地測試一些。
其次，在處理依賴于狀態的副作用或代碼時，有一些方法可以創建測試特定場景所需的上下文。其中一種方法是使用test doubles。
當然，我們需要對不是純函數的代碼進行測試。您可以盡量減少非純函數的代碼量（例如使用函數式編程），但如果您不這樣做，那么您的其余代碼也需要進行測試。
最后，您所說的“比率”或通常所說的“測試覆蓋率”取決于您對測試套件的信心水平。最后，正是這種信心使您可以重構代碼而不必擔心破壞事物，這最終才是重點。
慕姐4208626
TA貢獻1852條經驗 獲得超7個贊
在將測試對象與其通常環境隔離的測試中，您會input -> logic -> output經?？吹竭@種模式，因為輸入數據必須由環境提供，而測試是對象所經歷的環境。
TDD經常使用孤立的測試；它們通常既快速又令人尷尬地并行，這意味著在設計階段運行它們具有較低的機會成本。
String getName (int id)
{
// read the name of a staffmember out of the DB and return it
}
在像這樣的示例中，我們通常會被驅使設計“該”數據庫是可配置的，并且在我們的測試中，我們將提供預加載到正確狀態的內存數據庫。
// Copy input to database
// connect test subject to database
// invoke query, thereby retrieving the output
是一樣的圖案，只是雕刻的不同。
在許多情況下，我們可以在我們的設計中為數據庫引入一些抽象，并使該抽象而不是數據庫成為配置的依賴項。因此，與其使用與數據庫對話的抽象，不如使用更簡單的實現，通過硬編碼來返回一些值。
這樣的事情有時被稱為測試替身。
// Use the input to initialize the test double
// connect test subject to test double
// invoke query, thereby retrieving the output
同樣的模式再次出現，“邏輯”的細節發生了一些變化。
logicofinput -> logic -> output不一定是您的生產代碼。編寫與一個外觀集成的測試是很常見的，該外觀協調測試主體與其（雙重）依賴關系之間的交互協議。
（測試，就像生產代碼一樣，有設計——現在投資一個好的設計可能會在測試的整個生命周期內產生可觀的利潤）。
添加回答
舉報
0/150
提交
取消