假设您需要使用一个不必要的复杂、难以模拟(也许它有没有虚拟接口(interface)的具体类)和不可靠的第三方库，它与一些外部资源(如套接字或数据库)集成。您决定创建“包装器”接口(interface)/类以大大简化此库的使用并允许使用包装器的开发人员继续编写可测试代码。包装器的界面看起来与原始界面完全不同。
我有几个关于如何测试这个包装器的问题。
是否应该通过在可以模拟的坏库上开发一个方法对方法层来在没有外部资源的情况下测试包装器？
当您使用第 3 方库(使用外部资源)测试包装类时，这是单元测试还是集成测试？如果在自动化测试的时候外部资源可以嵌入到内存中，那还是集成测试吗？
我们在什么时候停止 mock 和 stub 并说我们有一个单位。根据维基百科，“单元是应用程序中最小的可测试部分。”但我发现这很难衡量。如果速度是决定我们是否正在测试单元的一个因素，那么您如何确定测试的速度有多慢才能称为单元测试？
最佳答案
TDD 并没有说一切都必须进行单元测试。 TDD 说你应该先写一个测试，但它不一定是单元测试。
- 从集成测试开始 - 它将测试您依赖于与真实组件通信的包装器的逻辑。这里没有 mock 。它是集成测试，因为它测试应用程序的多个层并且实际组件仍然使用套接字或数据库访问。
- 集成测试将失败，因为你没有你的逻辑
- 用模拟包装器编写单元测试来测试逻辑
- 单元测试会失败，因为你没有你的逻辑
- 编写满足单元测试(4.)的逻辑
- 重复 3.-5。获得满足集成测试所需的所有逻辑 (1.)
- 在下一个集成测试中重复整个过程
无需为包装器编写单元测试。主要包装器的功能是包装组件。如果您为包装器编写单元测试，您将测试它是否调用了组件上的方法，但在这种情况下，您又回到了起点——如何模拟组件？如果您仅为调用组件的包装器编写集成测试，那么您正在重新测试该组件(好的，这有时很方便，但在正常情况下您不会这样做)。
我推荐阅读 Growing Object-Oriented Software guided by tests史蒂夫·弗里曼和纳特·普赖斯。
关于unit-testing - 测试第三方库的智能包装器，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5924221/