涉及多個類的單元測試邏輯

我有一個評估方法的訂閱類。這個方法得到這個訂閱的計劃（作爲一個模型），然後這個獲得它的費用。通過此訂閱可以構建一個發票對象，其中包含上次結算日期未收費的費用。涉及多個類的單元測試邏輯

我想測試這個方法，但在我看來，這不會是一個單元測試，因爲它會涉及許多具有不同依賴關係的對象。

你會如何測試這種方法？

2011-01-18 Gabriel Solomon

你確定你不是說的'評估'方法？一個'屁股'方法聽起來有點不對勁;-) –

感謝您的領導:) –

這不是較真的單元測試（而一個集成測試），但它仍然可能是一個完全正常的測試:-)上和技術上你可以使用JUnit運行它（或任何你喜歡的單元測試框架），所以恕我直言，差別僅在於術語。

如果您從頭開始編寫代碼，最好的辦法是先單獨編寫針對單個方法的單元測試（嘲笑依賴關係），然後在下一階段添加更高級別的集成測試，例如您所描述的，以驗證你的課程能夠很好地協作。然而，在傳統項目（即大量沒有測試的繼承代碼）中，從細粒度的低級單元測試開始往往是不可行的;相反，編寫更高層次，更復雜的測試來澄清和「鎖定」更大組件的行爲會更高效。

遺憾的是目前在這個行業的大部分項目是傳統:-(對我來說，在這些情況下，pragmatism戰勝辦法手中的純度下降:-)

來源

2011-01-18 08:51:48

+1：關於遺留代碼的實用主義。 –

+1你不應該太在乎它是如何被調用的。如果該死的事情是容易出錯的，那就試試bejesus吧。 –

我經常使用CppUnit和JUnit來測試類的集合，這些類是迂迴*集成測試*而不是*單元測試*。事實上，你永遠無法避免這樣做。考慮有多少「低級類」實際使用STL或java.lang類。 – Raedwald

就目前來看，這聽起來像是一個集成測試，而不是單元測試。

如果您想單元測試涉及的方法，您應該嘲笑依賴關係（因此您使用Mock Invoice來返回已知數據）。然後，您可以分別編寫單元測試，以確保發票類正常工作。

來源

2011-01-18 08:47:31

恕我直言，使用模擬物體並不像許多人認爲的那樣必要。自下而上進行測試並接受可以測試類的程序集，這大大減少了模擬對象/測試間諜的需要。 – Raedwald

涉及多個類的單元測試邏輯

回答

相關問題