我正在編寫一個用於計算複雜數學公式的小工具（使用公用數學庫進行集成和根發現）。我試圖以與正常業務應用程序相同的方式編寫它，但是我發現我正在快速增加一些類。爲了得到計算的第一步（1個具有2個積分的直線公式），我已經爲計算的每一個小小點編寫了3個類，以便我可以使用依賴注入並正確地模擬所有對公共數學的調用。雖然有點失控，但我最終還是得到了20個類，這個類可以在一個類的兩個屏幕上解決（沒有單元測試）。你最喜歡的方法是什麼？我非常想要僅僅依靠這個接受和更高水平的測試。單元測試數學代碼
不要讓測試創建一個完全不可用的和難以理解的代碼。而且不要用面向對象的方法來過度發揮功能。
您正在測試一項功能，即無國籍之處在於產生相同的結果爲相同的參數。我認爲你應該如何測試它：從所有可能的等價類中給出它的論點，並對結果進行斷言。
+1：我同意。但是，不管你做什麼，都不要孤立地忽略這個函數的單元測試。如果你這樣做，當你試圖測試包含它的程序集時，你會後悔的。我從痛苦的經歷寫下。 – 2010-07-06 13:10:52
以我的經驗，你應該使用單元測試的完整性檢查和可能的迴歸檢查。單元測試當然應該儘可能徹底，但是有時完全測試代碼的全部功能是非常繁瑣的。
單元測試是不是一個正式的證明。他們不能也不會避免將來的錯誤和代碼問題。測試代碼的常見用例。如果您需要大量的可靠性，那麼您需要創建一個大型的迴歸測試庫。幸運的是，對於常見問題，有一些在線數據庫可用於此類事情。例如，其爲定理證明者的問題（和解決方案）的數據庫。
一種技術，有時對我的作品......通常在數學代碼，還有「容易，但慢」的方法，而「快，但很難編程」方法。編寫代碼時，你想使用快速但很難寫的（所以你期望錯誤）。所以...做出被測系統（SUT）的快速方式。當你進行單元測試時，創建1000個隨機問題並用「簡單但慢」的方法解決它們。然後，運行SUT並確保答案是類似的。
假設，當然......，創建隨機的問題是一個容易解決的問題。有時候是，有時並非如此。沒有你告訴我們數學代碼本身，很難說。現在...這是否得到所有的情況？不，但會得到「常見」情況。如果在實踐中出現拐角案例，請將其包裝在單元測試中，並將其修復到下一個版本的代碼中。
你談論嘲笑公用數學。我不會那樣做。 Commons-math是一段可靠，可靠的代碼。在測試中使用它而不是嘲笑它。這是否簡化了事情？ – DJClayworth 2010-07-06 13:23:07
如果您需要模擬20個課程，也許這些課程耦合得太緊密？ （高凝聚力）。 – 2010-07-06 13:26:05