为什么要做单元测试

标签：出现   反馈   如何使用   理解   复杂   项目开发   维护   一个   tdd   

为什么要做单元测试

通常我们在做任何工作会先考虑它的回报，编写代码更是如此。如果单元测试的作用不大，没有人会愿意再写一堆无用的代码，那么单元测试到底能够给我们带来什么优点呢？如下：

• 便于后期重构。单元测试可以为代码的重构提供保障，只要重构代码之后单元测试全部运行通过，那么在很大程度上表示这次重构没有引入新的BUG，当然这是建立在完整、有效的单元测试覆盖率的基础上。
• 优化设计。编写单元测试将使用户从调用者的角度观察、思考，特别是使用TDD驱动开发的开发方式，会让使用者把程序设计成易于调用和可测试，并且解除软件中的耦合。
• 文档记录。单元测试就是一种无价的文档，它是展示函数或类如何使用的最佳文档，这份文档是可编译、可运行的、并且它保持最新，永远与代码同步。
• 具有回归性。自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地地快速运行测试，而不是将代码部署到设备之后，然后再手动地覆盖各种执行路径，这样的行为效率低下，浪费时间。

等等，讲了这么多优点，无非就是良好的接口设计、正确性、可回归、可测试、完善的调用文档、高内聚、低耦合，这些优点已经足以让我们对单元测试重视起来了，但是个人觉得还有更重要的原因。

• 首先，带来自信。在接手一个新的项目，或者说是参与一个新的项目开发时，往往这种情况是你半途参加进去的，你需要对已有的代码结构进行解读和理解，对于业务的理解，对于代码个中各个模块关系的理解。如果一开始就理财出错，很可能修改后的代码会引起更多的BUG出现，到那时候又需要修复更多的BUG，改了一个地方，很有可能会莫名其妙地影响另外一个地方，这种现象是很常见的。还有一种情况，假设你修改的功能没问题，但是需要去测试验证，在测试的时候就需要考虑这个功能点它原有的测试路径有哪些，又需要一一去验证功能路径，以证明本次修改对于已存在的功能点不造成影响。这其中就存在着很大的时间成本，导致效率不高。那是否存在着这么一种方式，我需要修改我想改动的地方，不需要关心修改完之后它所造成的影响，也不需要关心它的测试回归性，有，此时就是单元测试登场的时候。写单元测试代码，可以让我自己写的代码足够自信，它是经得起考验的。
• 其次，更快反馈。对于有一定编程经验的开发人员来说，当他拿到一个新需求的时候，首先想到的不是动手 Coding ，而是会先想想代码的结构，有些类，数据结构该是如何，然后才开始敲代码。如果没有单元测试，一般流程基本是这个模块功能全部写完才开始测试，比如利用 MVP 架构的功能。一般都是开始 Model 模块,然后完善 Presenter 模块，最后写 View 模块，等这几个模块都写完了，再把 APP 跑起来，验证自己写的功能模块是否符合需求，没有符合则继续回去修改代码，这中间需要花费很长的时间才能知道当下自己写的代码是否符合要求，是否正确。那有没有一种即时反馈的方式呢，有，写单元测试即可，当你写完一个函数，马上就匹配一个单元测试函数，这样即写即测的方式可以保证你当场写的代码马上进行修改，测试通过一个，就表示完成一个小的功能点，最后，把函数组装起来，就是我们想要大的功能点。
• 最后，节约时间。对于 Android 开发来说，一遍一遍的运行 APP ，然后执行相应的用户操作，看界面是否正确的显示，通过这种方式来测试功能，其实是非常浪费时间，而且效率不高，而用单元测试，可以几乎不用打开 APP 来执行，当然有些需要一些资源文件的是需要 APP 运行条件，绝大部分的功能在单元测试阶段就能验证完毕，那么速度就相对快很多。此外，单元测试还能帮忙减少 BUG ，从而减少调试 BUG 的时间，一些低级犯的错误在单元测试阶段就能避免掉。

不写单元测试借口

很多开发人员不写单元测试，最重要的一个原因是他们并不知道单元测试能够带来什么好处，甚至根本不了解单元测试这个词，那自然就像平行线般与之毫无交集。还有一个比较重要的原因是一些开发人员的编程思想还处在一个相对初级的阶段，开发软件只管实现功能，什么高内聚、低耦合、重构、设计、可测试等认为太过专业，对于这些名词以及意义还不了解，这自然不会考虑使用了。还有一些非思想层面的理由，如下：

• 单元测试太花时间了。软件开发工作那么忙，代码都写不完哪有时间写单元测试。这可能是开发人员用的最多的借口，从某些方面来说，这不能算借口，因为很多开发人员确实在工作上投入的时间特别多。但真的是这样的吗，你有没有想过，导致加班的原因也许就是花了太多时间在手动测试、调试程序上：或许你没有考虑到灵活性与设计，使得在需求发生变更时你需要花很多时间在复杂的代码堆中完成特定的功能，而这些修改又可能引入新的 BUG ，又将导致你需要进行耗时的手动测试、调试等等，如此反复，代码将变得越来越乱，越来越难以维护，最终导致无休止的加班。
• 测试不是我的工作。测试确实不是开发人员的工作，但单元测试确实是开发人员的工作，测试包含很多种，而只有单元测试是开发人员的工作范畴。开发人员为应用编写代码，那么自然需要保证代码的正确性，而单元测试正是这种保证代码正确性的白盒测试，也就是在了解代码内部结构逻辑的情况下进行有目的的测试，既然说到了解代码，那么开发者自然是最权威的人。因此，编写单元测试并且为测试人员提交正确的代码进行其他测试是开发人员的职责所在。
• 代码都编译通过了，还测什么。一般来说，这是一个不会放在嘴上但可能藏在心里的借口。代码编译通过只能说你写的代码符合语法要求，并不代表能保证正确性。
• 代码原来就没有单元测试，并且难以测试。这个问题基本是接受和维护别人开发的代码，而原来的代码本身就没有单元测试了，再加入如果代码的耦合性较高，那么就更难以为这些代码写单元测试。此时正是你了解代码时候，首先为能够测试的部分添加单元测试，保证这些可测试的部分不会被污染，然后在对代码有足够的了解之后再对代码进行重构，降低代码的耦合性，并且慢慢补充测试用例，使得代码的耦合性、可测试性慢慢建立起来。

为什么要做单元测试

标签：出现   反馈   如何使用   理解   复杂   项目开发   维护   一个   tdd   

原文地址：https://www.cnblogs.com/yeagen/p/11712903.html