Using .NET Introspection / FxCop Rules functionality in Unit Tests

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 t开发者_C百科hat 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!

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.

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

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).