Add more interfaces to make FileHelpers mockeable

[MarcosMeli]

I have little background on working with advance mocking, mostly for mocking IO ops

So we need your help to identify the key points to make FileHelpers main classes mockeable

That addition must avoid breaking changes, in the worst case we can add some overloads but not change the way users work now with the library

[waynebrantley]

If using dependency injection and I want a constructor like this:

public MyClass( IFileHelperAsyncEngine<SomeClass> fileHelper)

I would have to register all the classes that could be used for the generic argument. However, if we had a IFileHelperClass marker interface that was put on every class that was intended for that use, I could generically register all the dependencies dynamically. Might it be nice to have the interface in the library and then some example automatic registration and use for users?

The problem with the above, is the IFileHelperAsyncEngine generic argument would contain ''where T : IFileHelperClass

If you put that constraint on the interface, that means we have the same constraint on the implementation, and that means every user would be required to mark the class with IFileHelperClass interface. This would of course be a 'breaking change' and users would have to add the (empty) interface to every filehelpers definition (not painful, but breaking)

The above applies to non-async too of course, but other than that I think the interfaces do what I need for DI.

[lilasquared]

@MarcosMeli I know this is a pretty old thread - has there been any progress on this? Particularly I am interested in mocking out the file system itself so that I can write unit tests that use the engine or other classes. I am currently using System.IO.Abstractions. Is there any way to mock where FileHelpers pulls the files from? Thanks!

Edit: To be more clear I know I can pull from a stream I was more wondering if there is a way to mock the underlying file system as a whole.