Reposted as answer and elaborated.
The fact that you're running unit test code that fails because of untrusted location is a sign that you're not doing unit testing, you're doing integration testing. This is brittle and prone to other problems, so I would try to avoid doing that as much as possible.
Unit testing should test small pieces of logic, units of code, like classes, methods, etc.
The second you pull in code that does one of the following, you're likely to have problems:
- Code that requires a database
- Code that requires a file (or file access)
- Code that talks to some external system (like a COM object, a web service, anything over a network)
For instance, what happens if:
- You run the unit tests on your own machine, but at home? Do you have access to the same systems?
- The database changes?
- The database is moved to a different server to free up some space?
- The disk is full?
- The network is down, or having hickups?
All of these things, and hundreds more, will cause your unit tests to fail, because not only are you testing the logic that sits on the other end of those connection paths, but you're also testing that the connection path works.
This causes your tests to be brittle, and prone to error.
When a test fail, you will always want to say "ok, we must've done something to break the code". You never want to hear this "argh, this test fails all the time, just leave it, it's probably the server again".
The reason your unit tests fails related to your question is that because the code is required to talk to an outside system (file, database, web server, network device), it requires elevated trust. If it only runs normal code, it doesn't require elevated trust, so your problem is a dead giveaway that you have such tests.
These tests are called integration tests, because not only do they test code, but they test how well your code integrates with the outside world as well.
I would try to remove those parts of the test, perhaps by refactoring them out, so that you can replace them with test systems in your unit tests.
For instance:
- If your code needs to write to a file, separate out the code to write to a file to a new class, in a method like
WriteToFile, wrap the class in an interface, and give the object to the logic code as a parameter. Then, in your unit tests, create a new class implementing the same interface, but that just records that the method was called, and not try to write anything to a file. This way you can test that "the method that was supposed to write to a file was actually called with the right data", and not "the file was successfully written".
For database and web servers and similar, you can do the same thing.
Finally, note that of course at some point you might want to actually run tests that ensures the file actually ends up on disk. However, you should separate all those tests out into their own project so that if they break, you know it's an integration test, all the unit tests should be able to run fine.