关于UT/FT用例的思考

本文目的

• UT/FT/接口用例，他们之间的区别，边界和使用场景
• 分享别人关于UT/FT的思考的火花
• 分享个人的思考

引子

1. 开发人员为什么要写用例？
2. 什么是UT/FT/接口用例，他们之间的区别，边界？

3. UT/FT/接口测试用例的使用场景，他们分别应该在什么时候被执行？
   

   UT与FT的边界

   

个人观点：

1. 执行单元用例，不会触发与外部服务交互的逻辑；
2. 如果有，那就是集成测试用例

UT与FT的区别

单元测试及其涵盖范围

Martin Fowler:
社交型的单元测试：受测对象会直接使用真实的依赖类别，让测试案例真实地运行一个完整的行为。
孤立型的单元测试：受测对象将不会使用真实的依赖对象。因为依赖对象发生错误，也会造成单元测试无法通过！为了确保受测程序不被影响，孤立型单元测试 会利用测试替身（Test Doubles）仿真并隔离依赖

小结：

社交型UT：就是常说的端到端的用例，通过事务驱动，用例在执行会覆盖到该行为的所有逻辑。
孤立型UT：非端到端，用例直接调用被测方法。通常使用mock来解耦依赖对象

端到端的UT用例

端到端：

非端到端：

个人观点：

端到端的用例在投入产出方面确实高效的多；非端到端用例由于涉及到大量中间对象的调用，不得不大量mock打桩，用例编写很乱，维护性差。（代码实例）所以我极力推崇在项目中用端到端用例覆盖特性的主要场景和功能逻辑。
但是，端到端的测试不得不对被测代码进行更多的改造和重构（代码实例），让被测代码具备更好的被测试性。而代码改造和重构的能力是需要长期的训练和积累的，同时，测试性的改造，偶尔会让领域代码牺牲一定程度简单设计原则（代码实例）0

代码实例

与外部进行交互的类：

• Repostory
• 中间件client(zk,redis,kafka等)
• ssh/http client等

思路：

找到与外部进行交互的类-->对类进行改造，增加父类，以及抽象方法-->实现faker类-->在测试用例中替换类的方法为faker类中的方法

单元测试是反人性的吗？

个人思考：

1. 对于“待蜕变”的程序员来说，要求必须写UT/FT用例，确实是反人性的。
2. 对于“蜕变“后的程序员来说，设计和交付用例的过程，恰恰是特性的深度挖掘，及功能全面设计的过程。
3. 从“待蜕变”到“蜕变”，任重而道远，但是也是自组织团队价值的突显。（项目赚的钱来源于员工自身成长带来的红利）

TDD

Test Driven Development is a development process. It is not about testing.

个人观点：

1. TDD是据我所知最适合重构代码/框架的思想，你可以不用，但是不能不懂。
2. 随特性代码一起交付的用例与代码本身同样重要

TDD不能代替UT

个人思考：

TDD编写的用例与QA的用例确实存在细微的差别：
TDD的用例更倾向于场景、功能的设计。
QA的用例侧重质量防护，TDD的用例侧重是新功能的拓展。

回顾

• UT/FT的区别，他们在交付的哪些环节被执行
• UT的涵盖范围
• UT用例价值和成本
• TDD的使用回顾