Question

每个人都告诉不要嘲笑你不拥有的东西。他们建议改为为第三方库创建一个包装器。

但是如何测试这个包装器？

我的意思是，如果我为它编写单元测试并且会模拟那些第三方接口来测试我的包装器，那么什么都不会改变。如果库维护者将更改其API，我将面临同样的问题 - 对于模拟库的测试将会很好，软件将在生产环境中失败。这里可靠性或可测试性的优势是什么？

我知道代码质量有优势，因为我可以随时交换这个库，但它不是这个问题的主题。

感谢。

Answer 1

有单元测试您的第三方库的抽象，以确保您的代码按预期运行，然后对第三方库进行集成测试，以确保这些集成的行为符合预期。如果那些第三方图书馆有沙盒，你可以安全地测试，甚至更好。

例如，如果您的系统正在测试一个依赖于第三方库但您想要在不调用实际库的情况下进行单元测试的系统。您可以手动或使用模拟框架提供第三方接口的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，行为将导致预期的行为失败。

希望这能满足你的要求。

如何对第三方库包装器进行单元测试？

1 个答案: