How to simulate File System on other platform

[markusschaber]

Hi,
As far as I can see, your mocked file system implementation supports the semantics of Windows, Linux and MacOS.

However, I could not find how to tell which semantics I want when creating an instance of the mock.

Our use case would be to test our code against a file system with Windows and MacOS semantics in the CI pipeline which currently only runs on Linux.

[vbreuss]

Hello @markusschaber,

That's a very interesting use case, I never thought about. Currently we mostly distinguish between file systems via the Execute methods, which would (at least in theory) be able to be changed, so that the behaviour could be overwritten. However there are also some other edge cases to consider (probably there are even more, but these just came to my mind immediately):

• All methods that rely on Path methods would need to be changed manually to use the correct directory separator depending on such a setting
• Some methods only work on the corresponding OS and rely on .NET features that are not supported on another OS, e.g. File.GetUnixFileMode has an UnsupportedOSPlatform("windows") attribute and would throw when running on Windows. This attribute could not be changed at runtime with a setting.

The primary goal of this library is to behave (as much as possible) the same as the real file system on the corresponding platform, so removing the attributes or relaxing some requirements, would not really be an option.

Do you have any ideas, how to overcome these challenges?
I would be happy to elaborate further on it!

[markusschaber]

The platform identification would neet to be instance members of the MockFileSystem, instead of statically accessing the Execute class. The default values would still reflect the current platform, so everything is strictly opt-in.

I had been falsely assuming that the mock implementation actually does not depend on any underlying file system code. You're right, some methods like Path would need reimplementation, so they can switch between behaviours at runtime. I guess the actual platform specific implementations could be gathered together from .NET itself (with appropriate attribution), as both projects use MIT license.

As far as I can see, the SupportedOSPlatformAttribute and UnsupportedOSPlatformAttribute are just for compile time analysis - I think their diagnostics could be suppressed for the test projects. The exceptions at runtime are actually thrown by the implementation, which could emulate the platform specific behaviour instead.

[vbreuss]

Let's talk about a possible approach:

1. Make the Execute class not static and adding it to the MockFileSystem with a constructor that can receive an OSPlatform enum and react accordingly.

2. Then we could add a method to replace it on the MockFileSystem, e.g.

   public MockFileSystem SimulatingOperatingSystem(OSPlatform osPlatform)
   {
     Execute = new Execute(osPlatform);
     return this;
   }

   and use this property instead of the static calls to Execute.

3. Update all Path-related calls to use a custom implementation instead.

4. Update tests, so that they also cover other OS platforms. Here I am still unsure, how to make sure, that the result matches the real file system.
   Any ideas?

5. At this point, we would probably run in some additional necessary changes 😄

Would you be willing to help with such a large change?

[markusschaber]

We should have the Tests run in 4 modes: Windows, MacOS, Linux and "native" - which is the OS we're actually running on.

I'm not exactly sure what's the best way to achieve this, as xUnit does not support parametrizing on the assembly/project level.

The approach I use is to write the tests in an abstract class, and then create a derived class per platform, where I just inject the platform in the base class via constructor.

I saw that there's quite some generated code, so maybe the multiplication could be wired into the code generator.

I'll check with my employer whether I get some permission to contribute some work.

[markusschaber]

I don't know the exact relationship between TestableIO and Testably projects. Which project would be the better place for this kind of contribution?

I've been under the impression that the Testably implementation might be the more advanced and "closer" to native FS behaviour, but we now have some unit tests which pass with native Windows and Linux FS, as well as the MockFileSystem from TestableIO 20.0.15, while they fail with Testably.Abstractions.Testing 2.6.1. (I did not have time to investigate any details yet.)

[vbreuss]

I wrote the Testably file system, because I had some requirements, that were not really feasible in the TestableIO testing helper. My main goal was to be as close as possible to the real file system, which is why all unit tests in Testably.Abstractions.Tests run both against the real and the mock file system (this is why I used source generators).
In order to simplify the transition, I worked in TestableIO to separate the interfaces from the wrappers and used the same interfaces.

The change you are proposing, is probably easier to implement here, even if it is still a huge change!

[vbreuss]

but we now have some unit tests which pass with native Windows and Linux FS, as well as the MockFileSystem from TestableIO 20.0.15, while they fail with Testably.Abstractions.Testing 2.6.1.

I would be really interested in these failing tests. Could you create issues for them, so that I can help investigating?

[vbreuss]

@markusschaber
I implemented some preliminary changes, so that the Execute and Test classes that encapsulate the OS-specific behaviour in the MockFileSystem and the tests respectively, are no longer static. The main obstacle now is, to implement the Path-specific behaviour in the PathMock class.

[markusschaber]

Thanks a lot. I still got no reply to my inquiry, but I intend to contribute.