c# - 在单元测试中验证交互是否会破坏封装？

Question

随着我对单元测试的了解越来越多，我开始意识到该领域众所周知的行为(交互)与状态验证方法。

在执行特定操作后验证某些系统的状态对我来说似乎是合乎逻辑的。

验证被测类与其他组件的交互是否也可以这样说？我仍然不是 100% 相信。

例如:

public void DoSomething(IDependency dependency)
{
    // some code ...

    dependency.Method();

    dependency.Method2();

    // some more code ...
}

DoSomething() 的当前实现调用 Method() 和 Method2() 并且可以使用模拟进行测试这一事实是否具有任何实际值(value)？

这两个方法的调用不是 DoSomething() 的实现细节吗？

与基于状态的验证相比，验证交互似乎要脆弱得多，而且还会破坏封装(测试被这种方法隐藏的东西)。

Answer 1

如果规范(有些人称之为测试)要求发生某种交互，您还应该验证情况是否如此，并为此进行单元测试。例如，如果要求 SUT 保存文件，您可能应该验证 IFileSystem.Save(...) 已被调用。如果要求 SUT 应该使用新文件名保护它(如果文件存在)，您应该验证 IFileSystem.Save(...) 已使用正确的文件名调用并且 IFileSystem .Exists(...) 已被调用。这是最好的交互测试。

使用 FakeItEasy它看起来像这样:

// arrange
var fileSystem = A.Fake<IFileSystem>();
A.CallTo(() => fileSystem.Exists("file.txt")).Returns(true);
A.CallTo(() => fileSystem.Exists("file1.txt")).Returns(false);
var sut = new SystemUnderTest(fileSystem);

// act
sut.DoSomething(); // do something that eventually saves file.txt

// assert
A.CallTo(() => fileSystem.Exists("file.txt")).MustHaveHappened();
A.CallTo(() => fileSystem.Exists("file1.txt")).MustHaveHappened();
A.CallTo(() => fileSystem.Save("file1.txt")).MustHaveHappened();