什么是UT？UT（单位测试）是单位测试
UT是什么值？大多数开发都不喜欢写UT，原因无非是以下内容：
简而言之，有无数的原因不想写UT。作为一名不到三年的新秀，它有了深刻的了解。在审查工作时，团队的“ UT”集中在RPC的服务器上。
为什么携带双引号？因为RPC的服务器无法运行页面，因此对测试环境测试的部署太麻烦了，只能写入UT.在此情况下，我认为它更适合“验证”和验证并不意味着测试。验证通常仅写入是否通过了主要逻辑，这是一种情况，并且没有断言，有些是system.out。
我在实习期间进行了测试，当时我知道一个测试模型。如下所示：
图片的含义是，底层越好，越好，越好。换句话说，大多数公司现在所做的功能测试实际上是最糟糕的测试方法。此外，QA上有一个场景行业：每个人都知道功能测试没有技术内容。我们怎么能使自己突出？答案是：自动化测试。实际上，很少有公司能在自动化测试方面做得很好，而且该行业做得更好。
那么为什么自动化测试很难做到？在此模型中，黑匣子越大，自动化测试的难度越大。该句子越多，自动化测试越好？最简单，最有效的自动化测试。因此，许多公司都有一个场景：QA写道。
原因是要总结两点：开发不愿意写UT，质量保证人想自动化测试以解放自己。UT的好处将实现UT的价值。
我相信单位测试和国际测试和集成测试的大部分开发都不清楚。个人理解单位测试对于具有最小业务逻辑的单元而言太抽象了。它可以轻松地理解为类方法，这可以是一种公共方法或私有方法。单元测试不应包括外部依赖项的逻辑，否则它是集成的测试。
那是问题的核心。
一个服务接口实现可能取决于许多第三方：
1.其他本地服务
2.DAO电话
3.RPC调用
4.微型服务电话。
如下所示：
换句话说，您的单位测试确实称为外部依赖关系。这很常见吗？让我们谈谈如何在这种情况下集成测试。
本地集成测试本地集成测试意味着它不依赖其他过程。包括：服务取决于其他本地服务或DAOS。在告诉如何集成测试之前，让我们看一下测试模型。测试主要包括三个内容：1。数据准备2.执行逻辑3.输出验证。
步骤1：在本地集成测试中的数据准备，数据的来源基本上来自DAO，DAO来自SQL。也就是说，在执行案例之前，执行一些SQL脚本，并且数据库使用内存数据库，例如H2。请记住不要依靠公司的测试环境DB。
下图是使用弹簧测试框架的情况。您可以在案件执行之前准备我们需要的各种数据。此外，在执行案件后，最初清理了clean.sql脚本。它还表明，案件的执行环境是完全独立的，重要的是不要彼此干扰很重要。
步骤2：最简单的执行逻辑是调用我们的测试方法。第三步是：验证集成测试通常是调用服务或DAO接口验证。
例如：CRUD操作的集成测试
远程集成测试假设我们可以依靠某个RPC服务
步骤1：数据准备运行到其他人的数据库并插入一些数据？或与PRC服务的所有者进行讨论，并为我们进行测试环境来测试吗？有些公司确实有专用的自动化测试环境。因此，即使有测试环境，如何实现各种情况方案，第三方服务也将数据归还给我们？考虑一下它会受到伤害。
步骤2：执行方法假设我们在第一步中成功解决了问题，所有这些都很高兴。现在看第二步，假设我们在服务中调用另一个RPC服务，并创建大量数据并运行无数时间。结果，与RPC服务相对应的数据库是我们的肮脏数据。如何清理？他们敢于随便删除数据吗？考虑一下疼痛。
步骤3：输出验证假设我们在第二步中愉快地解决了问题。现在看第三步，假设我们的方法执行最终输出是创建订单，那么订单当然是调用订单服务界面，那么我们如何验证该订单是否成功创建？也许您可以调用订单服务来查询验证订单的界面。显然，在大多数情况下，它并不是那么完美。以上分析，本地集成测试是可行的，远程集成测试基本上不可行。因此有任何方法可以解决吗？答案是模拟
单位测试我们谈论模拟问题可以解决外部依赖性的问题。现在有许多模拟开源框架，例如Mockito。因此，问题是，由于我们可以模拟第三党远程依赖关系，所以为什么不模拟DAO，本地服务？是的，外部依赖项被删除，这是单位测试。因为我们只关心所测试方法的业务逻辑，即真正收集的逻辑单元。如下所示：
好处如下：
有人会说他们还测试了一个鸡蛋。
这是对单位测试的理解。单位测试仅应测试目标方法的业务逻辑。DAO和其他服务应在其自己的单位测试中进行测试。对于第三方，我们应该相信他们可以正确地完成我们的期望。这句话难以理解，对吗？
举一些例子
示例1：最后一个方法是执行DAO的创建操作，那么如何验证？
我们应该验证的内容是：
是的，只要这三个验证通过，就会通过此案例执行。因为我们认为DAO的创建操作可以正确地完成我们的期望，只要我们称为正确的数字，并且参数是正确的。
保证在DAO的单位中测试DAO执行的正确性。远程集成测试的第三步是相同的。我们应该验证RPC界面被调用，数字和参数是正确的。这不是我们关心的。写作并不难。
何时使用单元测试以及何时使用集成测试？
在我自己的实践中，我发现对于简单的业务（例如Crud Thin Services），它更适合集成测试。以下情况适用于单位测试：
情况在多大程度上？这个问题也相对经典。如果涵盖了所有路径，那么应该写很多情况，这确实很累。我的建议是两个原则：1。核心逻辑，易于制作的逻辑逻辑必须涵盖2.根据您自己的时间。没有必要写很多。毕竟，案例的维护成本很高，商业逻辑已更改，并且案例必须改变。
总结我目前正在从事开源项目（Apollo）的研究和开发。开源项目的代码质量要求相对较高。当然，UT是一个非常重要的部分。一开始，我不会写UT，当然，我不关注UT的态度。
老板的代码UT覆盖范围很高，他慢慢接受了对开源态度负责任的学习UT。经过几种糖果之后，发现UT确实很实用，而且价值也很高，但可惜的是，UT大部分是UT的一部分，主要是其中大部分是其中的一部分。当然，我对UT的理解和练习还不够，我仍然需要继续练习模式。
最后，当开发功能（运行UT之后）可以轻松地上网时，您的UT成功了。