2013-03-15 73 views
2

我在考慮是否有任何框架/庫提供了一種機制來測試共享庫未導出的函數。對共享庫的私有函數進行單元測試

我想測試共享庫「t」部分列出的函數的工作。爲了測試「T」部分中的功能,我使用了cppunit。

測試場景: 存在使用中導出的類 「__ 屬性 __((可見性(」 默認 「)))」,其聲明瞭由具有「另一個類的可變__ 屬性 __ ((能見度(「隱藏」)))「,其在相同的庫中定義。 我想用「__ 屬性 __((visibility(」hidden「)))」屬性測試該類。圖書館的

編程語言是C++

編譯器GCC 4.1.2

平臺的RedHat/Solaris上

回答

2

如果你想使用它要運送相同的二進制文件來測試這些功能,我知道只有一個可行的解決方案:建立某種維護孔到您的libary。

這意味着,將一些公開導出的函數添加到調用您要測試的內部函數的lib中。使用這些函數的名稱來明確這些僅用於測試目的,它們不應該被lib的「普通用戶」使用。保持內部方法的文檔使外部人員很難使用它們。例如,以「TEST_」前綴開頭的所有方法都不會被普通用戶使用,並且隨着每個發佈版本的變化都可能會發生變化,因此請向官方文檔添加明確的警告。

如果有人不知道如何使用這種方法,只是不在乎 - 你無法阻止這樣的人向自己的腳射擊。

+0

Thankx @Doc Brown我也搜索了相同的東西,並提出了你在這裏提出的建議。我不是做很多測試函數,而是添加一個測試函數,返回測試結果的結構,並且該函數將調用所有其他測試函數。 – bikram990 2013-03-18 04:40:45

5

由於單元測試應該有代碼的深入瞭解他們測試,單元測試也可以使用一些代碼中的普通用戶無法使用的技巧。

可能的招數來這裏僱用有:

  • 確保單元測試和代碼下的測試鏈接爲一個可執行文件,而不需要先建立代碼被測在庫中。
  • 在構建單元測試時,使用預處理器宏來禁用可見性屬性。
+3

@ bikram990:單元測試無法/不會檢測到很多問題。因此,添加另一個級別的測試,通過僅使用其公共接口來驗證庫的正確功能。這就是我期望的黑盒釋放測試。 – 2013-03-15 12:30:40

相關問題