You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add option to specify operating system in MockFileSystem #778
I am working on library that is supposed to run on both Windows and Linux systems. To work effectively with files I am using MockFileSystem in my tests. I have several test cases where each one of them uses particular configuration file as input. Those config files contain file paths which may be either Windows or Linux style. This brings up a conflict between the file path style and the OS where the tests are running.
As an example please consider following code:
varroot="/home/folder";//this value is being loaded from config filevarsystem=newMockFileSystem();varfile=system.Path.Combine(root,"file.txt");
This works fine on Linux and the file variable contains "/home/folder/file.txt". However when the same code runs on Windows the result in file variable is invalid path "/home/folder\file.txt".
At the moment I have to translate all file paths to test machine OS style to be able to test all scenarios. However this is kind of intervention into the logic that is being tested and may lead to different behavior in production code.
As a solution I would appreciate to have an option in MockFileSystem class to specify operating system. MockFileSystem then should behave as if it runs on specified OS independently on real OS of the machine where tests are being run. As of now I just slightly looked into the code and I may not see all consequences and issues that may appear. However, in case that this feature requests will get some support and will be considered as feasible I offer my coding services.
Thanks for sharing your use case and offering your help.
We delegate most path operations to .NET(12) which in turn depends on the runtime OS. This makes it impossible for us to specify another OS unless we'd copy the entire .NET implementation, which I'd not consider sustainable.
I see, almost all of the functionality is delivered by static methods in Path. I agree that it might be an overwhelming to keep the pace with framework. Maybe a solution might be to provide public setter for MockFileSystem.Path property. One could create and use whatever implementation of IPath then. What do you think about that?
That makes sense! When #782 is merged you'll be able to use a custom implementation of IPath. Changes that are generally applicable can optionally be upstreamed to MockPath as we see fit.
Activity
fgreinacher commentedon Dec 17, 2021
Thanks for sharing your use case and offering your help.
We delegate most path operations to .NET(1 2) which in turn depends on the runtime OS. This makes it impossible for us to specify another OS unless we'd copy the entire .NET implementation, which I'd not consider sustainable.
What do you think?
onetocny commentedon Dec 17, 2021
I see, almost all of the functionality is delivered by static methods in
Path. I agree that it might be an overwhelming to keep the pace with framework. Maybe a solution might be to provide public setter forMockFileSystem.Pathproperty. One could create and use whatever implementation ofIPaththen. What do you think about that?feat: allow overriding properties of (Mock)FileSystem
fgreinacher commentedon Dec 22, 2021
That makes sense! When #782 is merged you'll be able to use a custom implementation of
IPath. Changes that are generally applicable can optionally be upstreamed toMockPathas we see fit.feat: allow overriding properties of (Mock)FileSystem (#782)
github-actions commentedon Dec 22, 2021
This is addressed in release v16.0.1.