4

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.

Steven
  • 166,672
  • 24
  • 332
  • 435
  • Do you want to be able to control the permission set under which a single test runs, or are you trying to perform multiple runs of a group of tests, applying a different permission set at each run? – Nicole Calinoiu Jan 17 '11 at 13:23
  • @Nicole: Thanks for your response. I would be glad if it is possible to run all tests in a single project within the same permission set, otherwise a per solution set would do. Per test would not be needed. – Steven Jan 17 '11 at 14:39
  • Is the target permission set for a project determined at design-time, or do you want to be able to dynamically set the permission set when executing the tests? – Nicole Calinoiu Jan 17 '11 at 14:41
  • If I could set the permissions once (for instance in the test library) it would be fine. Unit tests should never need to use the file system or a database. MSTest however would still run the assembly in full trust. How can we change that? – Steven Jan 17 '11 at 14:45
  • I was able to run partial tests with `NUnit` by applying [this](https://bitbucket.org/zastrowm/nunit.applicationdomain/src) extension code (modified). – shytikov Jun 17 '15 at 11:24

1 Answers1

2

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.

Nicole Calinoiu
  • 20,843
  • 2
  • 44
  • 49