在单元测试中使用 .NET Introspection / FxCop 规则功能
是否可以在单元测试中使用 .NET 自省功能？ 在我们的软件中，我想禁止使用某些操作（比较枚举值，因为有一种用于此目的的特殊方法）。我记得 FxCop（静态代码分析）通过内省提供对代码模型的访问。通过它，您可以检查某些功能是否被使用。我想编写一个单元测试来进行相同的检查，但我不确定是否为单元测试提供了内省或类似的功能。 或者也许你有另一个想法我该怎么做。
先感谢您！
is it possible to use the .NET Introspection functionality in unit tests?
In our software I#d like to prohibit usage of some operations (comparison of enum values since there as a special method for that purpose). I remember that FxCop (Static Code Analysis) ofers access to the code model by means of Introspection. With it, you can inspect whether some function is used or not. I' d like to write a unit test making the same check but I'm not sure whether Introspection or something similar is offered to the unit test.
Or maybe you have another idea how I could do it.
Thank you in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
似乎无法使用 FxCop 内部 外部（FxCop 本身或 Visual Studio 中除外）。
如果您想验证您的架构，可以尝试 PostSharp 功能架构验证或 FxCop Mono 替代品 Gendarme。
It seems that FxCop internals cannot be used externally (except in FxCop itself or in Visual Studio).
If you want to validate your architecture, you can try PostSharp feature Architecture validation or a FxCop Mono alternative Gendarme.
我不确定 FxCop，但您可以使用 .NET Reflection（这就是您所说的内省吗？）来强制执行某些代码行为。
例如，我在一些测试中使用了 Reflection，以确保某些“内部”类型不会通过我们的公共服务 API 公开。我们只是循环访问我们的公共 API，并验证“内部”类型列表中没有公开的类型（方法参数、属性等...）。当我们包装第 3 方组件时，这非常方便，但我们希望确保其库中的任何类型都不会通过我们的 API 公开。
如果您不熟悉 .NET 反射，它为您提供了一个 API，可让您查询类型以获取类方法、方法参数、类属性等信息...您可以从此处开始概述：
http://msdn.microsoft.com/en-us/library/f7ykdhsy(v=vs.71).aspx
I am not sure about FxCop, but you can use .NET Reflection (is that what you mean by introspection?) to enforce certain code behaviors.
For example, I have used Reflection in some tests to make sure that certain "internal" types are not exposed via our public service API. We just looped over our public API and verified that no exposed types (method arguments, properties, etc...) were in the "internal" type list. This was very handy where we were wrapping 3rd-party components, but we wanted to ensure that none of the types in their library were exposed via our API.
If you are not familiar with .NET reflection, it gives you an API which lets you query types for information like class methods, method arguments, class properties, etc... You can start with the overview here:
http://msdn.microsoft.com/en-us/library/f7ykdhsy(v=vs.71).aspx
借助 NDepend.API，NDepend 工具可以帮助您做到这一点。 免责声明：我是该工具的开发人员之一
NDepend.API 提出命名空间 NDepend.CodeModel 包含内省 .NET 代码库所需的所有类型和成员。
使用 NDepend.API，您可以编写单元测试来检查各种问题，例如 例如，未使用的方法。 NDepend.CodeModel 被设计为 LINQ 语法友好，并且 200默认情况下建议使用 LINQ 默认代码规则（用我们所说的 CQLinq）。
The tool NDepend can help you do that thanks to NDepend.API. Disclaimer: I am one of the developers of the tool
NDepend.API proposes the namespace NDepend.CodeModel that contains all types and member needed to introspect a .NET code base.
With NDepend.API you can write unit tests to check a wide-range of issues, like unused methods for example. NDepend.CodeModel has been designed to be LINQ-syntax friendly, and 200 of LINQ default code rules are proposed by default (written with what we call CQLinq).