Great idea. The method for creating the file should be somewhere else so we can simplify the client code. A good place is inside a TestServices class...

[SetUp] public void SetUp()
{
TestServices.CreateTextFile(webConfigPath, "MyNameSpace.something.txt");
}

[TearDown] public void TearDown()
{
TestServices.DeleteFile(webConfigPath);
}

You can also place these methods inside an ancestor of this Test class (assuming your test classes all descend from a common ancestor).

Actually, I do this sort of thing a lot, but have two utils that make it much easier - the source for both is on my coolcode blog (http://coolcode.darrenoakey.info)

TemporaryDirectory: the class gives you a temp dir in which you can work to your hearts content - as soon as the variable gets garbage collected, the temp dir gets cleaned up.

Resources: A much cleaner way of accessing resources..

Here's an example of how to use it - the actual test of the WriteResourceToFile function:

///
/// This tests writing a resource as a file
/// - create a temporary work dir
/// - write the firstSampleResource to a file
/// - read the file back, and check the values
[Test]
public void TestWriteResourcesAsFile()
{
// - create a temporary work dir
TemporaryDirectory newDir = new TemporaryDirectory();

// - write the firstSampleResource to a file
Resources.WriteResourceToFile( newDir, "firstSampleResource.txt");

// - read the file back, and check the values
Assertion.AssertEquals("read the file back, and check the values",
"This is the first sample resource",
CommonFunctions.ReadTextFromFile( newDir.FullPath( "firstSampleResource.txt")));
}