The example in the documentation for TestDrive:\ no longer work

[nohwnd]

The example in the documentation for TestDrive:\ also no longer works. It needs to be rewritten to use a BeforeAll block.

Originally posted by @markwragg in #1645 (comment)

[dgroh]

It would also great to add in the docs that Set-Content is needed in order to create the file otherwise it shows that file does not exist as well. How should we handle other file types like zip files for example?

[nohwnd]

TestDrive is no different than any other location on disk. In fact it is just an "alias" of %temp%/<some random path>, that will be cleaned up after your test finishes to make working with files more convenient to you. You would handle a zip file in the same way you'd handle it if it was on any other file path.

[nohwnd]

Or maybe I am misunderstanding what you tried to say.

[dgroh]

I understand how TestDrive work and I use it already mostly for json and text files. I had a case where I have a zip and for zip files IMO it doesn't make sense to use Set-Content. Here is my approach:

    $mockFile = "TestDrive:\File.zip"
    Set-Content $mockFile -Value "any content"

Maybe this is the way, but it just does not feel right!

[nohwnd]

I am still not sure what you are after. The documentation does not tell you to write zip files using Set-Content. It might be fine if you are just checking a presence of a zip file, but won't work if you try to unzip it. The documentation just shows one example of how to create a file on TestDrive, it does not force you to use Set-Content.

[dgroh]

Ok, I might be doing something wrong then, because without Set-Content I get an exception that the file does not exist.
And I don't expect to unzip the file, I just want to make the file available.

[nohwnd]

You are not doing anything wrong. 🙂 TestDrive points into an empty folder. This folder will be deleted once your top level Describe ends.

If you don't put any files in TestDrive the won't be any.

TestDrive is a way to give you a place on your disk:

• that is unique to each test suite, to avoid cross pollution between different test suites, while keeping sharing data between tests in a single suite reasonably simple.
• that you don't have to clean up. To avoid leaving your temporary files in your temp folder, or somewhere else on disk.