Basically, Mock is not a real thing, so it has no real behavior. He should not have real behavior - he should do everything that you tell him, watching what happened. Nothing more and nothing less.
This means that you must tell him how his copy method works. If you do the following, this will imply a copy method:
Mock<IDataSet> dataMock = new Mock<IDataSet>(); Mock<IDataSet> copyMock = new Mock<IDataSet>(); dataMock.Setup(c => c.Copy()).Returns(copyMock.Object);
However, you can also do this:
Mock<IDataSet> dataMock = new Mock<IDataSet>(); Mock<IDataSet> copyMock = dataMock; dataMock.Setup(c => c.Copy()).Returns(copyMock.Object);
and then the implementation of the Copy method becomes. Remember: an interface is not a contract that indicates what this method should do; it defines only the signature of methods.
You were probably hoping to copy data from one IDataSet to another, but remember that Mock is pure behavior; he has no data.
A few alternatives you might think of are the following:
- Replace IDataSet with the abstract DataSetBase class and implement the Copy method as you want it to behave (i.e. not as an abstract or virtual method).
- Instead of creating a Mock IDataSet, use Fake. Fake is a test implementation of an interface that has behavior that is close to real. There are no frameworks / libraries for creating fakes, so you will need to encode such a Fake manually.
- Consider whether the copy method should really be part of the interface. It seems to me that these are implementation details that are not related to the interface in the first place.
You can read about Stubs, Mocks, Fakes, and other patterns in the great xUnit Test Patterns book.