將 InternalsVisibleTo 用於單元測試代碼是否被認為是不好的做法？

Question

框架的AssemblyInfo.cs示例代碼：

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo
                          ("Test.Company.Department.Core")]

這是一種不好的做法嗎？

Answer 1

不，這不被認為是不好的做法。 如果您要測試的類出於充分的理由在程序集內部，則別無他法。 只是不測試它們會更糟。

Answer 2

個人覺得還好。 我從來沒有接受過“只測試公共方法”的教條。 我認為進行黑盒測試也不錯，但是白盒測試可以讓您使用更簡單的測試來測試更多場景，特別是如果您的 API 相當“笨拙”並且公共方法實際上做了很多工作。

同樣，在一個封裝良好的項目中，你很可能有幾個只有內部方法的內部類型。 現在大概這些會產生公共影響，因此您可以僅通過公共類型進行所有測試 - 但是您可能需要經歷很多麻煩才能實際測試使用InternalsVisibleTo測試非常簡單的東西。

Answer 3

我會說這是不好的做法，因為如果您使用了 SOLID 原則，那么您真的不應該使用“InternalsVisibleTo”。 但是我知道在“現實世界”中你會得到各種各樣的代碼......所以務實的方法是最好的。

此外，“InternalsVisibleTo”在您使用混淆的情況下並不理想。 混淆器傾向於混淆“內部”的東西。 因此，任何試圖引用混淆 dll 內部的外部 dll 都將失敗。 您顯然可以將混淆器配置為忽略外部引用的項目，但這會削弱任何混淆器的有效性。

在我看來，如果可以，請避免使用“InternalsVisibleTo”。 但是，如果您必須使用它，那么代碼的結構就會出現問題（您往往會從中受益）

Answer 4

如果您需要測試不想公開的 API 子部分， InternalsVisibleTo可能會很有用。

但是，最好通過公共 API 進行測試，因為這樣可以更輕松地重構內部 API。 小心使用InternalsVisibleTo ，並且僅在適當的時候使用，例如 API 的大小很重要。

Answer 5

我認為這樣做是完全合理的。

我發現它對於依賴注入非常有用。 如果我有一個帶有構造函數的類，它接受一些依賴項以允許對其進行單元測試，我經常將其標記為內部並在我的單元測試項目中公開它。 然后我會有一個公共（無參數，或者至少參數少得多）構造函數。 這使公共接口保持干凈，並且仍然允許可測試的代碼。

Answer 6

不，如果使用得當，因為在某些情況下它是必要的。 例如，您有單元測試A需要測試程序集B的公共成員，該成員使用也在程序集B定義的某些內部類型。 單元測試需要這種類型，因此您必須使用InternalsVisibleTo 。

它也可用於保護代碼。 例如，一個激活程序集。 您可能只希望解決方案中的一個模塊訪問您的激活程序集，並防止任何人添加對它的引用和調用方法。 您可以將類型和成員設置為內部，僅將它們公開給帶有公鑰令牌的簽名程序集，並且對世界其他地方隱藏。