Hi Roman,
Even if possible (FileStream has virtual methods I think, which is one precondition for mocking, but I'm not sure what it does in the constructor), I would not recommend it. I find faking out details of a chatty interface like this ends up giving me very little confidence that my code actually works. It is only a useful test if my fake works just like the real thing, in which case why not use the real thing directly?
What would you like to focus on for your test here? If you just want some confidence that it works as expected, I think I would write a test using a real file. This can be a bit painful to set up (getting working directories for the test correct etc), but is probably the best way to demonstrate that the code is doing roughly what you expect.
If for some reason you really wanted to use mocking for this (say, the file system overhead was too much, which seems unlikely but let's pretend), you could inject a dependency for loading the stream into the class:
IFileReader fileReader; // where IFileReader is your own interface, injected via the constructor
using (var stream = fileReader.GetStream(fileName)) // get the stream from the dependency
{
...
}
return data;
}
We could then stub out `GetStream` to return an in-memory stream or similar in your test:
var fileReader = Substitute.For<IFileReader>();
var classUnderTest = new MyClass(fileReader);
fileReader.GetStream("workingdir\\myfile").Returns(inMemoryStream);
var result = classUnderTest.LoadData<Sample>("myfile");
// assert result is as expected
But I don't think this is giving us much benefit over keeping your code as-is and using a real file and real FileStream.
Hope this helps.
Regards,
David