假设您需要使用不必要的复杂,难以模拟(可能它具有没有虚拟接口的具体类),以及与某些外部资源(如套接字或数据库)集成的不可靠的第三方库.您决定创建“包装器”接口/类以大大简化此库的使用,并允许使用包装器的开发人员继续编写可测试代码.包装器的界面看起来与原始界面完全不同.
我有一些关于如何测试这个包装器的问题.
>是否应该在没有外部资源的情况下测试包装器,方法是在可以模拟的坏库上开发方法方法层？
>使用第三方库(使用外部资源)测试包装类时,这是单元测试还是集成测试？如果外部资源可以在自动化测试期间嵌入到内存中,它仍然是集成测试吗？
>我们在什么时候放弃嘲弄和抄袭并说我们有一个单位.根据维基百科“一个单元是应用程序中最小的可测试部分”.但我发现这很难衡量.如果速度是决定我们是否正在测试一个单元的一个因素,那么您如何确定将该测试称为单元测试的速度有多慢？
TDD并没有说一切都必须经过单元测试. TDD说你应该先写一个测试,但它不一定是单元测试.
原文链接：https://www.f2er.com/javaschema/281467.html>从集成测试开始 – 它将根据与真实组件通信的包装器测试您的逻辑.这里没有嘲笑.它是集成测试,因为它测试应用程序的多个层,而实际组件仍然使用套接字或数据库访问.
>集成测试将失败,因为您没有逻辑
>使用模拟包装器编写单元测试来测试逻辑
>单元测试将失败,因为您没有逻辑
>编写逻辑以满足单元测试(4.)
>重复3.-5.获得满足集成测试所需的所有逻辑(1.)
>使用下一个集成测试重复整个过程
没有必要为包装器编写单元测试.主包装器的功能是包装组件.如果您为包装器编写单元测试,您将测试它在组件上调用方法,但在这种情况下,您回到开头 – 如何模拟组件？如果您只是为包装器调用组件而编写集成测试,那么您正在重新测试该组件(确定这有时很方便,但在正常情况下您不这样做).
我推荐Steve Freeman和Nat Pryce阅读Growing Object-Oriented Software guided by tests.
