企业官网建设流程全解析

小说网站怎么做词,建设工程东莞网站建设技术支持,办公室装修费用分几年摊销,公司网站开发的国内外研究现状目的 单元测试编写的目的#xff0c;是面向计算机特性的#xff0c;基于函数的in-out#xff0c;所以单元测试的好帮手就是断言#xff0c;通过不断的构造输出并对结果进行断言#xff0c;我们就可以针对一个对象以及它的函数#xff0c;构建出充足的用例去包裹它#…目的单元测试编写的目的是面向计算机特性的基于函数的in-out所以单元测试的好帮手就是断言通过不断的构造输出并对结果进行断言我们就可以针对一个对象以及它的函数构建出充足的用例去包裹它以期望它的任意行为满足我们的需要。最终的目的也是为了通过用例对单元测试的包裹达到对任意对象的任意函数进行修改后既满足新的功能又对旧有功能没有影响。原则基于单元测试编写的目的在编写单元测试时我们应当认为我们编写的单元测试所面向的过程是黑盒我们应只对输入以及我们期望的输出负责即只考虑起始输入以及最终态。具体来说针对Dao的单元测试我们只应该关心测试后数据库各个字段的值针对Service的测试我们只应该关心Service方法执行最终涉及到的数据库字段缓存消息队列中的值以及Service方法的返回针对Controller的测试我们仅应该关心Controller针对HttpRequst的输入以及HttpResponse的输出。而不该关心其中具体调用到的那些Service如何执行。其中第3点或许令人疑惑但是我们在编写单元测试时我认为应该仅考虑执行的函数逻辑本身。对于其外部的依赖或者并不关心结果的方法尽量mock掉。虽然目前的场景下Service层与Dao层基本耦合在一起无法拆分开来进行单元测试但是Controller层绝不应该严重依赖Service来进行单元测试否则单元测试最终会沦为接口测试。同时如果我们在测试某个模块时不对其外部依赖做mock那么就会导致我们的测试依然非常臃肿。并且最可怕的是我们对结果的断言无法实现。比如当我们对Controller进行单元测试时即便我们不mock它所依赖的Rpc而是将他们启动着但是我们如何对他所依赖的那些Rpc的执行正确与否进行断言呢难道我们要在Controller层的单元测试执行完成后在Controller层对数据库以及其他中间件的变化做查询以及断言吗这显然是不现实的。单元测试面向的应该是一个从不调用其他函数不包括第三方jar包的函数从其开始自底向上一个个编写直到Http接口层。对于同一个单元测试来说它的增加与修改应该与其对应测试功能的变化相同当对应的功能增加了或扩展了应在单元测试中对新增功能增加新的测试对老的单元测试则应该不做修改并保证新增功能也满足老的测试当对应的功能修改了并且不可能满足原有的测试此时才应当去修改原有的测试并应当加注释以说明。当需要修改单元测试时一定要谨慎因为这意味着以前的经验已经不奏效了。依靠这些原则去编写单元测试我们会发现想要写出一个好的便于测试的类也是比较难的。想要写出便于测试的类以及方法会反向要求了我们减少代码间的耦合提高代码的可读性。Timing单元测试的编写不应该是大家埋头一个月一起闭关编写虽然码上行确实需要这样而是一个不断渐进防止犯过的错再犯的方式。当开发一个新功能时我们应当对新功能针对需求编写单元测试这是理所应当的。当对一个功能进行修改时我们应该对该功能的单元测试进行修改并完成该功能修改后的单元测试。当发现某功能出现了某些意料之外的输出一般来说就是bug我们在修改时应当针对该种特殊情况编写对应的单元测试。经过以上3种情况的单元测试编写我们的单元测试会覆盖的场景就会越来越多我们的代码也会越来越健壮久而久之我们对于代码的修改可以纯粹依赖单元测试而减少更多逻辑上复杂的思考。感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取