为什么要停止单元测试?单元测试的首要使命(为什么要停止单元测试?)

[db:作者]

没有单元测试的考证在进修编程和营业开辟的工程中，我们已经会商过一段时候:单元测试有用吗？这类会商的首要缘由是，似乎项目不利用单元测试也能运转得很好他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。从结业设想的内容到十几小我的团队他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。我们设想项目，分析需求，然后按照设想成果写代码，然后对界面大概营业停止上述测试他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。在我们晓得写出来的代码可以完善完成计划的内容后，我们会请测试的同学帮我们停止代码测试，确保他们确切完成了计划的内容他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。终究代码上线了，可喜可贺他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
直到最初的题目出现才看起来不差他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
固然，我们会在开辟进程中测试项目标功用他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。常见的方式如用main考证指定的代码块或用postman测实考证我们设想的接口他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。也许中心还有一些数据库的点窜，比如模拟下单的数据大概模拟用户注册他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
这些方式在一定水平上可以完成当期的功用需求，否则不会有那末多类似“单元测试真的有用吗？”那末题目出在那里？
题目是，你不能一向保证“本期营业测试”可以覆盖你本期供给的功用点，而且即使测试同学保存了之前一切测试用例的自动化测试内容，也不能真正保证你的系统无缺，由于营业功用和软件功用是有差异的他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
虽然是搞笑的图，可是正确的击中了我想说的话:
为用例设想的功用测试不能保证你的“系统”是一般的他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
测试驱动开辟我们凡是在项目开辟中停止的功用测试可以保证当期的营业流程他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。可是，即使功用测试的进程包括了曩昔一切的功用，也只能保证营业流程是正确的，并不能保证你的设想在未来的扩大中是正确的(比如营业能够只需要一般的流程，而没有异常的流程)他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
是以，假如代码可以实现一切计划的功用，那末就要由开辟职员来编写他们响应的测试模块了他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。由于你是开辟职员，你晓得你一切的逻辑组合是什么，依照这个需求写出来的测试代码可以测试你的系统很长时候他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。这是:
测试驱动开辟
测试驱动开辟中最重要的标准是:
在编写营业代码之前编写单元测试他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
这条法则的目标是:不要写没有单元测试的代码他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。实在我们写功用营业的时辰，一般都是假定一个进口，然后经过一段时候的逻辑处置，最初返回一个成果他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。先写单元测试的目标是把你的假定间接放到代码里，这样你便可以在后续的编程进程中疏忽这部分假定，专心写逻辑他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。即使你终极忘记了之前的假定，也没关系，由于你已经把它写进代码了他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
该标准的进一步分化可以细化为三个标准:

写欠亨过的单元测试，就不能写生产代码他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。

只能写刚刚失利的单元测试，却不能编译他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。

只能编写足以经过当前失利测试的产物代码他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。按照细分三原则，我们可以把写一个逻辑的步调改成:写一个恰好失利的单元测试，然后用恰好合适逻辑的生产代码来满足它他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。这样的小循环能够一两分钟才发生一次他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。借助IDEA等现代ide，可以在测试包下的同一个包途径中建立响应的测试方式，大大加速了单元测试的编写时候他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。经过恰到益处的破例，控制每一次的营业逻辑，经过恰到益处的满足，每一个生产代码的编写都不会过度发散他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。假如您过度设想了产物代码，那末您还需要响应的单元测试代码来确保您的设想的适当性他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
假如依照这个周期来写，我们只需要十几秒钟便可以一边写营业代码一边完成单元测试他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。单元测试可以完全覆盖营业单元元素他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。可是随着营业代码的增加，测试代码的数目也会急剧增加，响应的治理也是一个应战他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
系统进化的保障回到最初的例子，我们说在一些团队中，我们总感觉单元测试效力低下，会影响营业的上线速度他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。我们也说，这个方式不到最初题目出现，看起来也不差他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。最初一个题目是:重建他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
这里的重构纷歧定是大范围的整系统统重构他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。我们在之前的文章《若何避免软件退化》中提到，为了连结软件设想的质量不退化，我们必须在每次需求发生变化时，按照变化点调剂原法式的设想结构他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
当我们调剂本来的法式结构时，我们不能保证对代码的变动会按预期工作，我们也不能保证系统中的一个点窜点能否会影响系统的其他部分他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。比如你点窜付出路子，假如出现意外，会致使其他付出方式生效他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。但假如保证功用一般，需要再次测试一切付出逻辑，仍有能够出现功用点的遗漏(这是小我经历)他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。由于我们惧怕新增加的功用带来更多的bug，致使加班，最初的结论是我们能够会抵抗功用结构的调剂，成为所谓的“狗屎上刻花”他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。所以从这个角度来说，假如没有单元测试，软件必定会线性退化他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
相反，假如我们的系统包括单元测试他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。我们不用担忧代码的点窜他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。每一次调剂都能经过那些“刚恰好”的单元测试，所以不管你若何重构设想形式，都不用担忧引入新的不成猜测的缺点他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
是以，有了单元测试，我们的系统便可以进一步保护和扩大，系统也就有了进化的能够他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
应当留意的单元测试我们需要单元测试来保证系统功用的扩大性和可保护性他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。但这并不意味着只要有单元测试他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。究竟上，我们应当像关注生产代码一样关注单元测试他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。缘由很简单:
单元代码也会随着功用调剂而损坏他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
假如它太败北而没法保护，没有人会想要点窜它他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。终极的成果是我们不需要单元测试，然后落空了代码的扩大性他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。是以，测试代码的点窜必须与营业代码的点窜同步停止，不能由于单元测试只在测试情况中运转而疏忽单元测试的编译他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。我们还需要使单元测试代码充足整洁，以便于保护他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
在测试的逻辑单元时，重要的是反该当前的测试内容，而让他人了解测试内容最重要的是测试的可读性他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。假如单元测试代码布满了一长串营业逻辑或断言，那末阅读起来将会很是困难他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。为了避免开辟职员沉没在代码的细节中，有一个众所周知的单元测试的机关方式:BUILD-OPERATE-CHECK，用given-when-then命名法来命名他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
举个例子(这里间接利用清洁代码的例子):
given pages(XXX)；when request issued(XXX)；thenResponseShouldBeXML()；
其中，在第一部分中，将机关的测试数据的内容分包到given开首的方式中；第二部分在when起头时将操纵测试数据的内容封装到方式中；第三部分将方式封装在then的开首，以检查操纵能否获得预期的成果他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
这样就屏障了大部分代码细节，测试的条件条件、处置进程、判定成果都间接用方式的名字来描写他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。同时，当我们触及到一些复杂流程的判按时，可以零丁编写一些额外的方式来支持单元测试他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。这样可以让人改变，让人快速了解单元测试的逻辑他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
对于轻松的部分，虽然我们需要连结单元测试代码的整洁，可是我们需要像关注生产代码一样关注它他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。但不代表我们的测试代码和生产代码完全一样他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。由于单元测试的原则是可读的代码，而且可以正确地描写所关注的测试功用鸿沟他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
所以有些内容不需要和生产代码分歧他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。最明显的是性能要求他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
我们需要在联机代码中优化系统性能，可是单元测试的代码是在测试情况中运转的，而且单个逻辑一次只履行一次他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。对于单元测试来说，0.1ms逻辑和1ms逻辑的区分能够并不明显他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。在这类情况下，我们能够会挑选一种更有表示力的方式来编写项目，比如利用“+”来拼接字符串他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。我们一般用StringBuilder，可是不能不说间接用“+”拼接可读性更强他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。此外，还有一些异步函数可以经过序列化来考证每一步的成果他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
单一概念为了保证每个单元测试中逻辑的可读性，我们希望每个单元测试只测试一个概念，这样便可以用一套give-when-then方式来描写这个测试概念他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。当我们发现单元测试中有很多概念时，我们会把它们拆开，别离测试他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。这样，在一个单元测试方式中聚合多个概念时，就避免了复合概念会为了袒护某些缺失的测试点而犹豫未定他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。同时也保证了单元测试的可读性他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。
其他原则此外，单元测试应当确保:

快速性:单元测试可以快速履行，并支持频仍测试他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。

自力性:单元测试互不依靠，可以在任何时辰以任何顺序履行他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。

可反复性:单元测试可以反复履行，而且成果是分歧的，否则总会有功用失利的捏词他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。

可考证性:单元测试应当经过布尔值来明白指示测试成果，而不是经过日志等其他帮助手段他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。

时效性:先写营业代码，复兴头写，让营业代码覆盖测试他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。最初，本文会商了单元测试的需要性和单元测试中的一些关键点他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。有人以为单元测试影响开辟效力，但从项目司理的角度来看，用单元测试项目是可以不竭进步的他早就发现系统有个隐藏的缝隙私下花了好几个早晨优化了代码。