How to verify if a stream has been copied on a fileSystem - unit-testing

Question

I want to write a unit test that check a stream has been copied on the disk :
The problem is CopyTo method is not virtual so I can't use
inputMemoryStreamMock.Verify(c => c.CopyTo(outputMemoryStreamMock.Object));
and I don't know how to mock a stream :-/
here is my test method :
[TestMethod]
public void Save_Stream_On_DestinationPath()
{
// Arrange
string fileName = "filename.pdf";
DateTime date = new DateTime(2013, 9, 27);
var serverConfigMock = new Mock<IServerConfigurationManager>();
serverConfigMock.Setup(config => config.ReportingBasePath).Returns(#"c:\reportsFolder");
var factoryReportFileResultMock = new Mock<IReportFileResultFactory>();
var timeManagementMock = new Mock<ITimeManagement>();
timeManagementMock.Setup(c => c.GetServerDate()).Returns(date);
var fileSystemMock = new Mock<IFileSystem>();
var fileInfoFactory = new Mock<IFileInfoFactory>();
var directoryInfoBaseMock = new Mock<DirectoryInfoBase>();
var inputMemoryStreamMock = new Mock<Stream>();
var outputMemoryStreamMock = new Mock<Stream>();
var reportFileHelper = new ReportFileHelper(serverConfigMock.Object, factoryReportFileResultMock.Object, fileSystemMock.Object);
inputMemoryStreamMock.Setup(c => c.CanRead).Returns(true);
outputMemoryStreamMock.Setup(c => c.CanWrite).Returns(true);
outputMemoryStreamMock.Setup(c => c.CanWrite).Returns(true);
fileSystemMock.Setup(c => c.FileInfo).Returns(fileInfoFactory.Object);
fileSystemMock.Setup(c => c.File.Create(It.IsAny<string>())).Returns(outputMemoryStreamMock.Object);
fileSystemMock.Setup(c => c.Directory.CreateDirectory(It.IsAny<string>())).Returns(directoryInfoBaseMock.Object);
// Act
reportFileHelper.Save(inputMemoryStreamMock.Object, fileName, timeManagementMock.Object);
// Assert
inputMemoryStreamMock.Verify(c => c.CopyTo(outputMemoryStreamMock.Object));
}
And here is the method to test :
public void Save(Stream portfolioReportFileInfoBase, string destinationName, ITimeManagement timeManagement)
{
string destinationPath = GetDestinationPath(timeManagement);
string destinationFileUri = Path.Combine(destinationPath, destinationName);
FileSystem.Directory.CreateDirectory(destinationPath);
using (var fileStream = FileSystem.File.Create(destinationFileUri))
{
portfolioReportFileInfoBase.CopyTo(fileStream);
}
}
Thank you

Answer 1

My take on a couple of things :
Readability
I'm not sure your test reads very nicely. Why do you declare a fileName variable as though it were important while you don't even assert on it ? Same goes for date. This clutters your test with unneeded detail. Inline values or Anonymous Variables allow for a better signal/noise ratio.
Then why do you set up CreateDirectory() to return something ? You never use that return value, do you ? I suggest you get rid of that and the directoryInfoBaseMock variable. Same with FileInfo and fileInfoFactory. Your test needs to contain the bare minimum to set up the objects you want to verify, and nothing more. If you need to build a deep, complex graph of objects just to test one simple thing, there's generally a problem somewhere.
Design
The second thing that raises an alarm is that Save() mixes multiple language levels. When you read it, it seems to be at the same time about :
Portfolios and reports
Time management
A lot of lower level filesystem stuff
This is often a sign that an object tries to handle too much, violating the Single Responsibility Principle.
What I would do is distribute these responsibilities across separate objects.
Why does Save() need to know about time management ? Sure, we use time management to compute the destination path, but wouldn't it be better aligned with the language level and responsibility level of a Save() method if we directly passed it the destination path instead ?
Why does Save() need to know about portfolios and reports ? Well, there's basically no reason. You could just rename portfolioReportFileInfoBase to... stream.
Save() and GetPath() could then be moved to a separate lower-level filesystem wrapper class (IFileSystem is a perfect candidate), removing the tight coupling between ReportFileHelper and the filesystem.
Don't try to test that your report is written to the disk using mocks. Do it with an integration test. Don't mock types you don't own. Use mocks only to test how your own classes talk to each other. Wrap external libraries/platforms into wrapper objects, and write integration tests at the boundaries of your application to verify that your wrappers play well with those external libraries/platforms.

Answer 2

You'll have to use an isolation framework like TypeMock Isolator or Microsoft Fakes to test this case if you're not willing to change the code of the Save method, since CopyTo can't be mocked by Moq.
You already encapsulated access to the filesystem behind IFileSystem; why not just add a method like CopyStreamToPath?
public void Save(Stream portfolioReportFileInfoBase, string destinationName, ITimeManagement timeManagement)
{
string destinationPath = GetDestinationPath(timeManagement);
string destinationFileUri = Path.Combine(destinationPath, destinationName);
FileSystem.Directory.CreateDirectory(destinationPath);
FileSystem.CopyStreamToPath(portfolioReportFileInfoBase, destinationFileUri);
}
and the test:
fileSystemMock.Verify(c => c.CopyStreamToPath(inputMemoryStreamMock.object, It.IsAny<string>()));