I stumbled upon the need to have a mockable Environment.CurrentDirectory property. Quickly looking at its implementation, it's calling Directory.GetCurrentDirectory(), which is, unfortunately, not yet implemented in System.IO.Abstractions.
If someone (I) were to write an abstraction for System.Environment, would you consider merging it into System.IO.Abstractions? (it doesn't really belong to IO, but it uses several things from System.IO directly).
One could write up an article saying that how you'd abstract it. The problem is that Environment.CurrentDirectory isn't itself written to support that dependency injection itself.
How would you abstract it?
IMO, Basically any code using Environment.CurrentDirectory would have to be changed manually to FileSystem.Directory.GetCurrentDirectory()
Typically, yes, this is what I ended up doing in my particular case, then I discovered that GetCurrentDirectory was not (yet) implemented in System.IO.Abstractions.
I'd abstract System.Environment just like File and Directory are currently abstracted - an abstract decorator, EnvironmentBase, and a EnvironmentWrapper, forwarding the calls to the real System.Environment class.
The real challenge is creating a "MockEnvironment" helper, which could be easily programmed to return correct data in a test.
But also, Environment.CurrentDirectory is just the tip of the iceberg. Many useful, un-injectable things exist within the Environment class, things that are very hard to mock without wrapping them yourself.
What if you start with a pull request for Directory.GetCurrentDirectory(), then we can work out what to do with Environment next?
Its a tough one, but theoretically you wouldn't want to start going down this rabbit hole, as @tathamoddie suggests.
We need a better campaign to convince Microsoft to start including dependency injection libraries like System.IO.Abstractions into the core framework so that all that "other" code, that we may call into, could be testable too.
With the framework going into "Open Source Mode", I'm wondering if the core BCL team at Microsoft could seriously start to consider phasing out things like Environment.CurrentDirectory in favor of more testable implementations
Of note, when looking at a C# library for VHDs, I realized that IFileSystem abstraction is SOOOO important... because theoretically your FileSystem could be repointed to a VHD with an undo disk, thereby simulating mmmmmmmmmmuch more situations being called for here in issues for MockFileSystem (like Readonly and out-of-space conditions). Or even an IFileSystem implementation that "clones" the current system, where you could test interactions with existing structure while isolating and abstracting the test-library changes from that filesystem.
@tathamoddie you may see me send over some pull requests related to that type of work, expanding IFileSystem a bit to provide support for the C# library for VHDs, ISOs, etc... basically "filesystems in a box" of sorts...
there is already a discussion dotnet/corefx#312