为什么做UTDD（单元测试驱动开发）

为什么做UTDD

前言导入

        天下熙熙皆为利来，天下攘攘皆为利往。
        在开始做一件事情之前，我们首先需要弄清 “它能给我们带来什么？(好处、坏处)”
        以免出现壮志满满地开始，却在实践中发现它一无是处，最后只能不了了之的情况。日后，回忆起这整个实践过程，一肚子苦水，那可真是“哑巴吃黄连，有苦说不出”。

明显好处

   督促你写出整洁可用的代码、帮助你达成质量内建的目标、帮助你编制一张系统保护网....

• 督促你写出整洁可用的代码

  • Kent Beck在《测试驱动开发》一书中，就开宗明义地提出：UTDD的所追求的目标是 Clean code that works（代码简洁可用）。

    • Code that works: 代码首先必须可用——单元测试

    • Clean code: 代码应该尽可能简洁——重构

  • 采用UTDD，在编写单元测试用例之前，你需要进行 需求分析、考虑程序的可测试性。

  • 并且你只能填充刚好让用例通过的程序逻辑代码，从而有效避免了过度设计，软件代码做到了 “可用”。

  • 正因你频繁地重构单元测试用例、程序逻辑代码，软件代码做到了 “整洁”。

• 帮助你达成质量内建的目标

  • 采用UTDD，你所写的每一行程序逻辑代码，都是为了通过单元测试用例。

  • 那么换而言之，你所写的每一行程序逻辑代码，都通过了单元测试用例。

  • 这是一种极大程度的“测试左移”，那是不是能极大程度享受“测试左移”带来的好处？

• 帮助你编织一张系统保护网

  • 当你使用UTDD进行程序编码时，同时无形中也在为软件系统编织一张保护网（单元测试用例）。

  • 当有新的变化需求或重构代码时，你可以大刀阔斧地去做，因为有张保护网替你兜底（回归测试）。

  • 即使时过境迁，这张保护网依然能有效地保护系统的边界，能避免让你的系统成为“烫手的山芋”。

• 降低你开发时的思绪负担

  • 在日常软件开发工作中，你是否会有 “思绪万千” 的感觉（不知从哪动手、如何动手）。

  • 而UTDD能有效解决这一问题；UTDD的基本流程：红->绿->重构，一个完整闭环。

    • 我们在软件编程的过程中，主要几个关注点：需求、设计、实现。

    • 红：写一个让程序运行失败的单元测试用例，它是对一个小需求的描述，只需要关心输入输出，这个时候根本不用关心如何实现。（需求）

    • 绿：专注在用最快的方式实现当前这个小需求，不用关心其他需求，也不要管代码的质量多么惨不忍睹。（实现）

    • 重构：既不用思考需求，也没有实现的压力，只需要找出代码中的坏味道，并用一个手法消除它，让代码变成整洁的代码。（设计）

  • 其实这和软件分层架构的思想 如出一辙——“关注点分离”。

• UTDD当然还有非常多的好处：提前澄清需求、快速反馈....

潜在风险

     凡事都有两面性，UTDD的引入也是有代价和风险的：

1. 学习成本：团队人员初学UTDD，团队推广实践UTDD都是有成本的。

2. 开发成本：开发人员需要编写、维护测试用例，所带来的时间、工作量成本。

3. 其他代价：可参考 TDD is dead. Long live testing. (DHH)

4. 总而言之，团队拒绝UTDD的主要原因在于难度大、工作量大、Mock的大量使用导致很难测试业务价值等。

    所以，对于团队来说，UTDD的引入是一把双刃剑，具体要根据项目的实际情况、使用场景以及贯彻程度，做出决策。

更多文章，请移步至：https://blog.csdn.net/qq_41998273/category_11699499.html

参考文章

《测试驱动开发》作者：Kent Beck
 深度解读 - TDD（测试驱动开发） - 简书