單元測試構造函數是否重要？

Question

我應該對單元測試構造函數嗎？ 說我有這樣的構造函數：

IMapinfoWrapper wrapper;
public SystemInfo(IMapinfoWrapper mapinfoWrapper)
{
    this.wrapper = mapinfoWrapper;
}

我是否需要為這位建築師編寫單元測試？ 我沒有包裝器變量的任何getter，所以我不需要測試它。

Answer 1

單元測試是關於測試對象的公共狀態，行為和交互。

如果您只是在構造函數中設置一個私有字段，那么有什么要測試的？

不要打擾單元測試你的簡單訪問器和mutator。 那太傻了，對任何人都沒有幫助。

Answer 2

是。 如果構造函數中有邏輯，則應測試它。 簡單地設置屬性不是邏輯IMO。 條件，控制流等IS邏輯。

編輯：您應該測試IMapinfoWrapper何時為null，如果需要該依賴項。 如果是這樣，那么這就是邏輯，你應該有一個測試來捕獲你的ArgumentNullException或者其他......你的測試是定義代碼行為方式的規范。 如果它拋出ArgumentNullException，那么應該在測試中指定。

Answer 3

問：如果要在構造函數中設置成員變量，為什么要設置它。

答：因為你有一個失敗的單元測試，只能通過在構造函數中設置它來傳遞。

如果您使用此邏輯，只編寫代碼以使單元測試通過（測試驅動開發），那么您已經有了問題的答案。

Answer 4

不會。它的功能將通過課堂上的每個其他單元測試進行測試。

Answer 5

你絕對應該測試構造函數。 如果您有默認構造函數，則應測試是否可以調用它。 如果稍后更改類會怎么樣 - 也許它會變成單例或刪除默認構造函數而不是需要參數？ 在這種情況下，測試應該失敗以警告該更改（以便可以修復類或測試以滿足新要求）。

默認構造函數的存在是應該進行測試的要求。 即使所有構造函數都設置了將在其他地方測試的私有成員，也應測試存在無參數構造函數的事實。

Answer 6

我在構造函數包含邏輯時進行測試 - 例如驗證或條件設置私有狀態。 驗證錯誤最終在構造函數拋出的異常中結束。 成功執行最終會創建一個對象，該對象根據構造函數中設置的狀態顯示特定的行為。 無論哪種方式，都需要測試。 但構造函數測試很無聊，因為它們看起來都一樣 - 調用構造函數，進行斷言。 測試方法聲明通常占用比整個測試邏輯更多的空間......所以我寫了一個簡單的測試庫，它有助於為構造函數編寫聲明性測試： 如何在C＃中輕松測試構造函數中的驗證邏輯

這是一個例子，我在一個類的構造函數上嘗試七個測試用例：

[TestMethod]
public void Constructor_FullTest()
{

    IDrawingContext context = new Mock<IDrawingContext>().Object; 

    ConstructorTests<Frame>
        .For(typeof(int), typeof(int), typeof(IDrawingContext))
        .Fail(new object[] { -3, 5, context }, typeof(ArgumentException), "Negative  length")
        .Fail(new object[] { 0, 5, context }, typeof(ArgumentException), "Zero length")
        .Fail(new object[] { 5, -3, context }, typeof(ArgumentException), "Negative width")
        .Fail(new object[] { 5, 0, context }, typeof(ArgumentException), "Zero width")
        .Fail(new object[] { 5, 5, null }, typeof(ArgumentNullException), "Null drawing context")
        .Succeed(new object[] { 1, 1, context }, "Small positive length and width")
        .Succeed(new object[] { 3, 4, context }, "Larger positive length and width")
        .Assert();

}

通過這種方式，我可以測試我的構造函數的所有相關情況，而無需輸入太多內容。

Answer 7

在許多由FDA監管的環境中，更關鍵的代碼必須經過100％的測試......包括類的構建。 因此，無論是否進行測試，都需要對構造函數進行測試。 此外，使用靜態分析工具的公司需要確保正確初始化類的所有數據成員，以便不會出現錯誤，盡管代碼可以順利運行且沒有錯誤。 通常數據成員初始化在構造函數中完成...只是值得深思。

Answer 8

這取決於。

我不打算為你給出的例子這么簡單的東西寫一個專門的構造函數測試。

但是，如果您在構造函數中進行了邏輯測試，例如參數驗證，那么絕對是。 雖然像原始海報一樣，如果可能，我在構造函數中不起作用，但通常必須進行參數驗證。 在這種情況下，不可避免地使構造函數不做某些工作。 如果構造函數中存在邏輯，那么它總是存在錯誤的可能性，因此我將其視為任何其他方法調用並對其進行適當測試。

Answer 9

我認為答案是肯定的。

有很多代碼可以假設一個初始化的對象狀態，而不是空引用 - 通常在構造函數中沒有指定顯式值時。

我很高興在初始化的公共成員值被更改時，構造函數測試會中斷以提醒我。 這是關於防御性測試 - 我是務實的，並且更樂於接受測試，並且當它們被證明沒有幫助或有用時將它們移除。

Answer 10

除非開發人員確保不能更改狀態邏輯，否則還必須測試訪問器和更改器。 例如，如果使用Singleton的設計模式，通常會使用訪問器或屬性，如果未初始化類，則由訪問器完成，因為構造函數是私有的。 在C ++中，可以使其函數為const或static，其中類的數據成員不能更改。 （注意：即使使用靜態也有點風險，因為這些變量通常是全局的。）但是，如果沒有測試，如果有人未能使用預防措施，您如何能夠100％准確地保證所寫的內容不會成為故障時間？ 維護很難萬無一失。

Answer 11

我相信100％的報道。 此外，100％的覆蓋范圍不僅僅是通過模擬事物或只是設置和獲取事物來測試簡單的交互，而是通過檢查功能的更多集成/驗收測試。 因此，如果您最終編寫了非常好的集成/驗收測試，則應調用所有構造函數（以及諸如setter和getter之類的簡單方法）。

Answer 12

SystemInfo實例的行為取決於wrapper的值？

如果出現任何問題（例如，空值導致破損），那么我建議編寫描述每種情況的場景，並使用它們來推動相應單元測試的定義。

如果所有場景最終都依賴於IMapinfoWrapper的私有實例的狀態或行為，那么我建議在該類上編寫單元測試。

Answer 13

除非您正在編寫編譯器，否則您只會測試編譯器是否可以生成執行分配的代碼，這通常是沒有意義的。

現在，在更常見的情況下，如果你想用包裝器做其他事情，那么也許有一點。 例如，如果您嘗試傳遞null，則可以拋出ArgumentNullException，理論上，可以進行單元測試。 即使這樣，測試的價值也非常小。

就個人而言，我幾乎從不明確地測試構造函數。 如果它們足夠復雜以至於需要測試，我傾向於覺得代碼有點臭的一面。

Answer 14

如果構造函數包含一些邏輯，比如初始化一個類，我認為你應該測試一個非常構造函數。 或者您可以與開發人員討論在構造函數中放置初始化會降低測試代碼的可測試性。

Answer 15

單元測試是關於檢查執行路徑，通常稱為Cyclomatic Complexity

如果你沒有可供選擇的路徑，沒有if，沒有循環，沒有GOTO（= P）它不是很有用