你的單位測試有多深？我發現關于TDD的事情是它需要時間來設置你的測試并且自然是懶惰我總是希望盡可能少編寫代碼。我似乎做的第一件事是測試我的構造函數已經設置了所有的屬性，但這是否有點過分？我的問題是你在單元測試中寫出了什么級別的粒度？..是否有一個測試太多的情況？
3 回答
侃侃無極
TA貢獻2051條經驗 獲得超10個贊
我得到的代碼是有效的，而不是測試，所以我的理念是盡可能少地測試以達到給定的置信水平（我懷疑這種信心水平與行業標準相比很高，但這可能只是傲慢） 。如果我通常不會犯一個錯誤（比如在構造函數中設置錯誤的變量），我不會測試它。我確實傾向于理解測試錯誤，所以當我有復雜條件的邏輯時我會格外小心。在對團隊進行編碼時，我會修改策略以仔細測試我們共同出錯的代碼。
不同的人會根據這個哲學有不同的測試策略，但這對我來說似乎是合理的，因為對于測試如何最適合編碼的內循環的理解不成熟。從現在起十年或二十年后，我們可能會有一個更普遍的理論，即哪些測試要寫，哪些測試不寫，以及如何區分。與此同時，實驗似乎是有序的。
飲歌長嘯
TA貢獻1951條經驗 獲得超3個贊
為您希望破壞的事物和邊緣情況編寫單元測試。之后，應該在bug報告進入時添加測試用例 - 在編寫bug修復之前。然后開發人員可以確信：
錯誤是固定的;
該錯誤不會再出現。
根據所附的評論 - 我想這種編寫單元測試的方法可能會導致問題，如果在給定的類中發現了大量的錯誤。這可能是自由裁量權有用的地方 - 僅針對可能重新發生的錯誤或重新發生會導致嚴重問題的錯誤添加單元測試。我發現單元測試中的集成測試測量在這些場景中會有所幫助 - 測試代碼路徑更高的代碼可以覆蓋更低的代碼路徑。
斯蒂芬大帝
TA貢獻1827條經驗 獲得超8個贊
一切都應盡可能簡單，但并不簡單。 - A.愛因斯坦
關于TDD最容易被誤解的事情之一就是其中的第一個字。測試。這就是BDD出現的原因。因為人們并不真正理解第一個D是重要的，即Driven。我們都傾向于對測試有所了解，對設計的驅動有點關注。我想這是對你的問題的一個模糊的答案，但你應該考慮如何驅動你的代碼，而不是你實際測試的; 這是Coverage工具可以幫助您的東西。設計是一個更大，更有問題的問題。
- 3 回答
- 0 關注
- 573 瀏覽
添加回答
舉報
0/150
提交
取消