對不起有服務依賴單元測試，如果我要求很基本的問題，如何編寫其他服務或數據庫
我已經設置了一個Web服務（使用的.Net開發的WebAPI）。這些服務是業務層或數據訪問層API。這些API要麼依賴於其他服務或數據庫本身。
我想爲它編寫單元測試用例。我有以下問題
隨着業務層的API對數據訪問服務或其他一些服務的依賴。如果我編寫單元測試只是爲了調用業務API，那麼它會調用數據訪問API。這是編寫單元測試用例的正確方法嗎？或者我應該注入所有的依賴對象與單元測試？我認爲早些時候將會是集成測試而不是單元測試。
我應該爲數據訪問層編寫單元測試嗎？我檢查了這個鏈接（Writing tests for data access code: Unit tests are waste），它說DAL不需要單元測試。我還應該爲數據訪問層編寫測試嗎？我認爲這將是集成測試而不是單元測試？
我會說，如果你想要做TDD，那就不是「正確」的方式，因爲如你所說，你會進行集成測試。然後，也許你不要想做TDD和集成測試對你來說已經足夠了，但要回答這個問題：這不會是** unit - **測試你的代碼的正確方法。
我會說這取決於你在你的數據訪問層。例如，如果你實現了倉庫，你可能會想寫幾個測試。
你要確保考慮到您從庫中檢索，編輯該實體的一些性質和持續性的變化實際上將保存修改結果，而不是創建一個新的實體的實體。現在：您可能認爲這是一個集成測試，但這取決於您的代碼設計得有多好。例如，您的存儲庫可能只是在低級別ORM之上的額外邏輯層。在這種情況下，當測試save方法時，您將要做的是您將聲明正確的方法是使用注入庫中的ORM服務的正確參數調用的。
當訪問數據，有可能有問題，例如連接到數據庫被破壞，或者未如預期的數據的格式，或反串行化的問題。如果你想提供一些很好的錯誤處理，並可能創建自定義異常並根據上下文添加更多信息，那麼你一定要編寫測試以確保正確的信息傳播。
如果你的DAL只是幾個包裝非可嘲諷的ORM的類，並且你沒有任何邏輯，那麼也許你不需要測試，但是這似乎也不會發生通常，你幾乎總會有一些邏輯可能出錯，而你想測試。
對於2，我認爲這取決於您的DAL中有多少業務邏輯。如果有可測試的邏輯，那麼單位測試可以幫助使代碼可靠。如果DAL只是在做簡單的CRUD操作，我認爲它對UT來說不合適。對於1，最佳實踐建議您的所有服務都應該實現接口。如果用戶界面 - >業務 - > DAL，則可能有IBusiness和IDAL，通過UT模擬和假貨使每個界面都可以測試。 –
我認爲，人們聽起來太想聽起來像是「正確」或「聰明」了。有測試可以防止迴歸是一件好事*。無論這些測試是觸及數據庫還是不觸摸數據庫，在事情的宏偉計劃中都無關緊要。測試==好，沒有測試==不好。話雖如此，如果你想要純粹的單元測試，你應該注入僞裝實現的所有依賴關係。我喜歡FakeItEasy，但還有其他框架可以幫助你做到這一點。如果DAL執行的邏輯超出了讀取和返回數據的範圍，則應該對其進行測試 –