Si confía en que su conjunto de pruebas no será "abortado" a mitad de la prueba, puede utilizar los métodos FixtureSetup y FixtureTeardown para establecer y luego eliminar sus variables de entorno modificadas.
EDITAR DEL COMENTARIO: Veo de dónde vienes, pero como en mi edición, se ha diseñado un marco UT para crear pruebas unitarias. El concepto de una prueba unitaria dicta que NO debe depender de ningún recurso externo, incluidas las variables de entorno. Las pruebas que hacen esto son pruebas de integración, y requieren una gran cantidad de infraestructura para estar en su lugar (y, por lo general, toman muchas veces más tiempo que un conjunto de pruebas unitarias de igual LOC).
Para crear una unidad pruebe el código que depende de una variable de entorno, considere dividir las líneas de código que realmente examinan las variables de entorno directamente. y poner eso en un método en otra clase, luego simular esa clase usando RhinoMocks o lo que sea para proporcionar un valor "ficticio" para las pruebas sin examinar (o cambiar) las variables de entorno reales.
Si esto realmente es una prueba de integración y realmente necesita la variable de entorno establecida (digamos que está cambiando la ruta para que pueda usar Process.Start para llamar a su propio notepad.exe en lugar de Windows), eso es lo que Los métodos/atributos FixtureSetup y FixtureTeardown son para; realizar una configuración complicada de un entorno fijo y repetible en el que las pruebas deberían tener éxito, y luego restablecer el entorno tal como estaba, independientemente de lo que haya sucedido en las pruebas. Normalmente, una falla de prueba arroja una excepción y finaliza la ejecución de la prueba inmediatamente, por lo que no se garantiza la ejecución del código al final del método de prueba.
¿Está ejecutando MSTest desde la línea de comandos (Dos/PowerShell)? ¿O desde Visual Studio? – Rob
Desde Visual Studio 2008, disculpe si eso no estaba claro. Usar el Run Runner predeterminado, etc. –