大家都说“别嘲笑不属于你的东西”。他们建议为第三方库编写一个包装器(wrapper)。
但是,我应该如何测试这个包装器呢?
我的意思是,如果我为它编写单元测试,并将那些第三方接口(mock)来测试我的包装器(wrapper),那么什么也不会改变。 如果库维护者更改其API,我将面临相同的问题-模拟(mock)库的测试将顺利进行,但软件将在生产环境中失败。 在这里,可靠性或可测试性的优势是什么呢?
我知道这会对代码质量有好处,因为我可以随时更换这个库,但这不是这个问题的重点。
谢谢。
大家都说“别嘲笑不属于你的东西”。他们建议为第三方库编写一个包装器(wrapper)。
但是,我应该如何测试这个包装器呢?
我的意思是,如果我为它编写单元测试,并将那些第三方接口(mock)来测试我的包装器(wrapper),那么什么也不会改变。 如果库维护者更改其API,我将面临相同的问题-模拟(mock)库的测试将顺利进行,但软件将在生产环境中失败。 在这里,可靠性或可测试性的优势是什么呢?
我知道这会对代码质量有好处,因为我可以随时更换这个库,但这不是这个问题的重点。
谢谢。
有单元测试可以对第三方库的抽象进行测试,以确保您的代码按预期运行;还有针对第三方库的集成测试,以确保这些集成的行为符合预期。如果这些第三方库有沙盒可供安全测试,那就更好了。
例如,如果您的系统受到第三方库的依赖,但想在不调用实际库的情况下进行单元测试,则可以手动提供第三方接口的模拟实现,也可以使用模拟框架。
public interface IExteralContract {
List<string> DoSomething(params string[] args);
}
[TestMethod]
public void SUT_Should_Be_True {
//Arrange
IExteralContract mock = new MockExternalContract();
var sut = new MyClass(mock);
//Act
var actual = sut.DoSomethingElse();
//Assert
Assert.IsTrue(actual);
}
public class ConcreteExternalWrapper : IExteralContract {
public List<string> DoSomething(params string[] args){
//Actual calling of 3rd party libraries
}
}
[TestMethod]
public void Third_Party_Service_Should_Return_Data {
//Arrange
IExteralContract sut = new ConcreteExternalWrapper ();
int expected = 3;
//Act
var actual = sut.DoSomething("arg1", "arg2", "arg3");
//Assert
Assert.IsNotNull(actual);
Assert.AreEqual(expected, actual.Count);
}
这样,如果库维护者更改其API,则行为会导致预期的行为失败。
希望这能满足您的要求。