可测试性战术分析

Posted 2020-11-27 aduorisk

　　本篇博客参考《信息领域热词分析》，设计实现可测试性战术。

　　首先我们要了解一下可测试性，软件可测试性是指通过测试（通常是基于运行的测试）揭示软件缺陷的容易程度。

　　接下来就介绍在项目开发中运用的可测试性战术：

　　1.面向对象编程

　　作为一名软件工程的学生，我们都知道编码原则：

• 单一责任原则
• 开放/封闭原则
• 里氏代换原则
• 接口分离原则
• 依赖反转原则

　　不论是在爬虫爬取信息阶段，还是热词统计阶段，还有最后的可视化展示，都离不开这些原则。尤其是遵循了单一职责原则和接口分离原则后，面向接口编程，

　　每一个函数或者对象，都只完成单一的功能，主函数只对其进行调用或传参，可测试性就会大大提高，这些原则会引导我们持续重构。

　　2.使用设计模式

　　上学期我们学习过设计模式这门课程，设计模式其实是代码经验的总结。

　　比如策略模式，策略模式定义了一组算法，将每个算法都封装起来，并使它们之间可以互换。这个模式让法算法的变化独立于客户端的调用。

　　

 

　　　　

 　　3.面向接口编程

　　面向接口编程

　　面向接口编程有两层含义：类级别，面向接口编程； 方法级别，面向函数接口编程。

　　比如 A 对象依赖 B 对象里的 M 方法，而 M 方法会从数据库里读取数据。那么 A 就不要直接依赖 B 的实体类，而引用 B 的接口。 当对 A 编写单测时，只要注入 B 的 接口实现即可。 同理，方法中含有 service 调用时，不要直接依赖 service 调用，而是依赖函数接口，在函数接口中传递 service 调用，如上面的做法。

　　假设有 m1, m2, m3 方法，m1调用m2, m2调用m3, m1, m2 都是纯函数, m3 会调用外部服务依赖。由于 m3 不纯以及调用关系，导致 m1, m2 也不纯。解耦的方法是面向函数接口编程。 m3 不依赖于外部服务，而是依赖函数接口。在 m3 的参数中提供一个函数接口，m1, m2 传入一个 lambda 表达式。如果 m1, m2 也有很多业务逻辑要测试，那么 m1, m2 也提供相同的函数接口传入服务依赖，直到某一层只是一层“壳函数”。 这样，含有业务逻辑的方法都可以方便地单测，而且更容易理解（函数接口表达了需要什么外部依赖）， 而壳函数不需要单测。 当然，这需要对编程方式和习惯的一种改变，而目前大部分编程习惯就是直接在方法里调用service，看上去直观，却会导致方法耦合了外部依赖，难以单测。