测试第三方库的智能包装器 [英] Testing smart wrappers for 3rd party libraries

问题描述

假设您需要使用不必要的复杂，难于模拟(也许它具有不带虚拟接口的具体类)以及与某些外部资源(例如套接字或数据库)集成的不可靠的第三方库.您决定创建包装器"接口/类，以大大简化该库的使用，并允许使用包装器的开发人员继续编写可测试的代码.包装器的界面看起来与原始界面完全不同.

Suppose you are required to use an unnecessarily complicated, difficult to mock (perhaps it has concrete classes with no virtual interface), and unreliable third-party library that integrates with some external resource such as a socket or a database. You decide to create "wrapper" interfaces/classes to greatly simplify the usage of this library and to allow developers using the wrapper to continue to write testable code. The wrapper's interface looks nothing like the original interface.

关于如何测试此包装器，我有几个问题.

I have a few questions about how to test this wrapper.

1. 是否应该通过在可以模拟的坏库上开发方法层来测试包装器而无需外部资源?

1. Should the wrapper be tested without the external resource by developing a method-for-method layer over the bad library that can be mocked?

当您使用第3方库(使用外部资源)测试包装器类时，这是单元测试还是集成测试?如果在自动化测试期间可以将外部资源嵌入到内存中，那么它仍然是集成测试吗?

When you test your wrapper classes with the 3rd party library (using the external resources) is this a unit test or an integration test? If the external resource can be embedded in memory during the automated test, is it still an integration test?

在什么时候我们退出模拟和存根，并说我们有一个单元.根据维基百科，单元是应用程序中可测试的最小部分."但我发现这很难衡量.如果速度是决定我们是否要测试单元的因素，那么您如何确定将测试称为单元测试的速度太慢呢?

At what point do we quit mocking and stubbing and say that we have a unit. According to wikipedia "A unit is the smallest testable part of an application." but I am finding this difficult to measure. If speed is a factor in decide whether or not we are testing a unit, how do you decide how slow is too slow for the test to be called a unit test?

推荐答案

TDD并不表示必须对所有内容进行单元测试. TDD表示您应该首先编写一个测试，但这不必是单元测试.

TDD doesn't say that everything must be unit tested. TDD says that you should write a test first but it doesn't have to be a unit test.

1. 从集成测试开始-它将测试依赖于包装器的逻辑，该包装器将与实际组件进行通信.这里没有模拟.这是集成测试，因为它测试应用程序的多层，并且实际组件仍使用套接字或数据库访问.
2. 集成测试将失败，因为您没有逻辑
3. 使用模拟包装器编写单元测试以测试逻辑
4. 单元测试将失败，因为您没有逻辑
5. 写出满足单元测试(4.)的逻辑
6. 重复3.-5.获得满足集成测试(1.)所需的所有逻辑.
7. 通过下一个集成测试重复整个过程

不需要为包装器编写单元测试.主要包装器的功能是包装组件.如果为包装器编写单元测试，则将测试它是否调用了组件上的方法，但是在这种情况下，您又回到了起点-如何模拟组件?如果您只为调用该组件的包装程序编写集成测试，则您正在重新测试该组件(好的，这有时很方便，但是在正常情况下，您不需要这样做).

There is no need to write unit tests for wrapper. The main wrapper's function is to wrap the component. If you write unit test for wrapper you will test that it calls method on the component but in such case you are back at the beginning - how to mock the component? If you write integration test just for wrapper calling the component you are retesting the component (OK this is sometimes handy but in normal scenario you don't do that).

我建议阅读通过测试引导的面向对象软件史蒂夫·弗里曼(Steve Freeman)和纳特·普赖斯(Nat Pryce).

I recommend reading Growing Object-Oriented Software guided by tests by Steve Freeman and Nat Pryce.

这篇关于测试第三方库的智能包装器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！