我有一個簡單的項目，主要由後端服務代碼組成。我有完全的單元測試，包括我的DAL層...我應該單元測試我的網格渲染邏輯嗎？
現在我必須寫前端。我重新使用我的前端可以使用的業務對象，並且有一個網格呈現一些輸出。我有我的DAL對象有一些稱爲DisplayRecords（id）的函數，它顯示給定ID的記錄...
所有這些DAL對象都經過了單元測試。但是爲DisplayRecords（）函數編寫單元測試值得嗎？這個函數調用一個存儲過程，它正在做一些連接。這意味着我的單元測試將不得不建立多個表格，其中一個具有15列，並且其返回值是一個DataSet（這是我的DAL中返回數據集的唯一函數 - 因爲它不值得創建一個對象只是這個網格）...
這樣的東西，甚至值得測試？一般前端邏輯怎麼樣？人們傾向於跳過ASP.NET前端的單元測試，就像人們跳過私有函數的邏輯一樣嗎？我知道後者有點不同 - 測試行爲與實現以及所有......但是，我只是好奇一般的經驗法則是什麼？
非常感謝
有重達到是否應該編寫測試的幾件事情：
這是關於信心。您建立測試，以便您有信心進行更改。你可以自信地做出沒有測試的變化嗎？
此代碼對應用程序的使用者有多重要？如果這對所有事情都至關重要，那就測試一下。
如果你有迴歸，這有多尷尬？在我的最後一個項目中，我的目標不是迴歸 - 我不希望客戶必須兩次報告相同的錯誤。所以每個重要的bug都會在測試修復之前進行測試。
編寫測試有多困難？有許多工具可以幫助緩解疼痛：
硒的理解和直接設置。在硒中維護一個大型測試套件可能有點貴。你需要夾具數據才能工作。
假設在其他地方進行了測試，使用模擬來剔除DAL呼叫。這樣可以節省創建所有燈具數據的時間。這是測試Java/Spring控制器的常見模式。
簡單地將代碼以其他方式分解，以便可以對其進行測試。例如，提取格式化特定網格單元的代碼，並編寫單元測試，而不考慮視圖代碼或實際數據。
我傾向於迅速做出Selenium測試和坐視不管應用程序做它的事 - 這就是它避免了所有的手動點擊快速驗證方法。
完全自動化的用戶界面測試很乏味，應該只在更爲成熟的應用程序中完成，因爲用戶界面不會有太大變化。關於'中間'代碼，我會測試它是否被重用和/或複雜/引入了新的邏輯，但是如果它只是或多或少地是一個新的DAL方法調用序列並且特定於單個視圖，我會跳過它。