I like to be able to run MSTest in partial trust. This would allow me to configure what the code, that my unit tests call, can and can't do.
The problem I'm trying to solve is to let my automated (unit) tests fail when things like the file system, database, system clock and other external resources are used. By running in partial trust I can configure what type of actions the AppDomain may and may not do. This allows me to detect places in the code that do not correctly abstract away the used resources.
If there are other ways of achieving this, please let me know.
Unfortunately, MSTest does not have a built-in mechanism for this, and changes to CAS policy application in .NET 4.0 have severely restricted the supported approaches for this.
The simplest approach to this would be to restrict the CAS permission grant on the AppDomain created by MSTest to run the tests in a particular test assembly. However, current versions of MSTest do not allow interception and/or customization of AppDomain creation. We can't work around this by adding code to an AssemblyInitialize method since AppDomain policy changes made after code starts running in the AppDomain have no effect.
This basically leaves us with a single supported mechanism for applying CAS permission restrictions for testing: applying a PermissionSet.PermitOnly from within a test method or code that invokes the test method. e.g.:
[TestMethod]
public void SomeTest()
{
SomeStaticTestUtilityClass.TargetPermissionSet.PermitOnly();
// Run the rest of your test code here.
}
It may be possible to do this via custom test attributes using the approach described at http://blogs.msdn.com/b/vstsqualitytools/archive/2009/09/04/extending-the-visual-studio-unit-test-type-part-1.aspx. However, I haven't tested this, and I'm not sure if the test method invocation mechanism would allow applying the PermitOnly in a manner that would result in it's being present on the call stack for the tested code.
If you have a lot of these to author and use of a custom ITestMethodInvoker either doesn't work or is otherwise unsuitable, another option would be to use a post-compiler like PostSharp to insert the PermitOnly calls.
If none of this suits, and you're not married to MSTest, you might also want to consider changing your test framework to one that is more easily extensible.