在C中，應該爲頭文件或C文件編寫單元測試

Question

我有一個包含struct和一些方法聲明的頭文件和一個定義（實現）結構和方法的'C'文件。在編寫單元測試用例時，我需要檢查是否修改了一些結構變量（沒有getter方法）。由於結構的定義包含在C文件中，單元測試用例是基於頭文件還是C文件？

Answer 1

測試組件的接口可用於系統的其他部分，您的情況的頭部，而不是接口的實現細節。

單元測試對組件的行爲做出斷言，但不應該取決於該行爲如何實現。測試描述什麼組件，而不是它如何它完成。如果你改變你的實現，但保持相同的行爲，你的測試仍然應該通過。

如果您的測試取決於特定的實現，那麼它們將變得脆弱。更改實施將需要更改測試。這不僅是額外的工作，而且會讓測試應該提供的保證無效。如果您可以針對新的實現運行現有的測試，那麼您可以確信新實現沒有改變其他組件可能依賴的行爲。一旦您必須更改測試以便能夠針對新的實施運行測試，您必須仔細考慮是否在流程中更改了測試的任何期望。

測試無法使用此組件的公共接口訪問的行爲可能很重要。考慮一下這個界面可能設計不好的好提示。 TDD鼓勵採用「測試第一」的方法，這就是其中一個原因。如果你首先定義你想要關於組件行爲的斷言，那麼你必須設計一個暴露該行爲的接口。這就是過程「測試驅動」的原因。

如果您必須在測試組件後編寫測試，那麼至少應該嘗試利用這個機會重新評估設計並從您的測試中學習。這種行爲是一個實現細節，不值得測試，否則應該更新接口來公開它（這可能比公開它更復雜，因爲系統的其他組件也應該安全合理，以便現在訪問它公共屬性）。

Answer 2

我建議全部除開發過程中由開發人員執行的短暫事情外，測試應該測試API而不是內部測試。畢竟，你需要滿足規範。

因此，如果你維護的東西是而不是對外界可見，那本身並不是需要直接測試的一個方面。相反，假設有錯誤影響外界，它的那效果你應該測試。

封裝器件可自由完全更改，恕不外界底層的實現受到影響，你會發現，基於外部來看，將不需要做任何改變，如果你做出這樣的，如果你編寫你的測試更改。

因此，舉例來說，如果你的單位是一個地址簿，你應該測試的東西沿着線：

• 我們可以插入一個條目？
• 我們可以刪除它嗎？
• 我們可以檢索它嗎？
• 我們可以插入一百個條目並以隨機順序查詢它們嗎？

它不之類的東西：

• 做結構數據字段得到正確創造出來的？
• 鏈接列表內部一致嗎？