项目管理第三章模拟练习，卓越工程之单元测试在行权鉴权中的实践
项目管理第三章模拟练习，卓越工程之单元测试在行权鉴权中的实践1.用户发起查询时，首先判断用户传入的参数中是否包含行权验证的字段，如果不包含则直接抛出异常，提示鉴权失败；包括单元测试在内的所有测试都应该对所需要测试的流程有比较清晰的认识才能保证测试的用例不被遗漏，保证测试质量，因此在撰写单元测试前，首先需要对所测试部分代码的流程进行梳理。1.全书内容比较枯燥乏味，虽然有部分代码示例，但是语言并不生动，让人坚持读下去就很难。2.书中强调，每做一次代码的重构，即使修改很小的部分，也应该对修改进行测试，所以在看到书中举例的各种重构和重构后的不断测试时，就对测试和重构打起了退堂鼓因为对代码的测试缺少整体的认知，对单元测试也一直停留在简单的print层面，直到在这几天通过一个阅读打卡活动，系统性的学习了大量关于单元测试的理论、实践知识和在代码重构中的帮助，重新让我回忆起《重构》书中所提到的知识点，一直跃跃欲试，所以也想尝试将单元测试实际应用在自己写的业务代码
简介： 在去年的时候就读过《重构：改善既有代码的设计》这本在代码重构领域里的经典，当时在读的时候就苦于有这么两点导致只停留在了“读”上面，而缺少实践。
作者 | 邱庆羽(羽哲)
来源 | 阿里开发者公众号
前言在去年的时候就读过《重构：改善既有代码的设计》这本在代码重构领域里的经典，当时在读的时候就苦于有这么两点导致只停留在了“读”上面，而缺少实践。
1.全书内容比较枯燥乏味，虽然有部分代码示例，但是语言并不生动，让人坚持读下去就很难。
2.书中强调，每做一次代码的重构，即使修改很小的部分，也应该对修改进行测试，所以在看到书中举例的各种重构和重构后的不断测试时，就对测试和重构打起了退堂鼓
因为对代码的测试缺少整体的认知，对单元测试也一直停留在简单的print层面，直到在这几天通过一个阅读打卡活动，系统性的学习了大量关于单元测试的理论、实践知识和在代码重构中的帮助，重新让我回忆起《重构》书中所提到的知识点，一直跃跃欲试，所以也想尝试将单元测试实际应用在自己写的业务代码中，为自己的代码“保驾护航”，同时在代码中有单测，在重构的过程中单测也会让自己不慌张，修改代码后直接执行一下单测就可以对修改后的准确性进行验证。这篇文章着重在“实践”上，是对Java编程技巧之单元测试用例编写流程这篇文章的实际应用，并没有高深的理论和技术。
流程包括单元测试在内的所有测试都应该对所需要测试的流程有比较清晰的认识才能保证测试的用例不被遗漏，保证测试质量，因此在撰写单元测试前，首先需要对所测试部分代码的流程进行梳理。
1.用户发起查询时，首先判断用户传入的参数中是否包含行权验证的字段，如果不包含则直接抛出异常，提示鉴权失败；
2.在鉴权中，因为行权可能会由多个字段组合鉴权，因此需要对全部鉴权字段进行遍历。在鉴权时，还会有匹配字段，包含：
- 等值匹配（=）
- 前缀匹配（like xxx%）
- 后缀匹配（like %xxx）
- 模糊匹配（like %xxx%）
四种形式，当用户输入参数与匹配字段不相符时，记作鉴权失败。
3.当用户没有输入参数中的权限时，记作鉴权失败。
4.在多个鉴权字段进行组合时，还会存在两种组合逻辑：and（所有字段均需要有权限才能访问）和 or（任意字段有权限即可访问），所以还会结合组合逻辑进行综合权限判定。
测试边界在明确了代码的流程后，就需要对测试边界进行明确，测试应该着重对边界情况进行测试，因为清晰的单元测试边界划分有利于构建更加稳定的系统核心代码，因为我们在推进测试边界的过程中会不断地将副作用从核心代码中剥离出去，最终会得到一个完整且可测试的核心，而我们的核心代码就是处于测试边界内的。下图将所有的情况做了枚举，作为单元测试的用例。
引入依赖
其中，powermock.version为2.0.9，为当前的最新版本，可根据实际情况修改。在PowerMock包中，已经包含了对应的Mockito和JUnit包，所以无需单独引入Mockito和JUnit包。
点击链接查看原文，获取更多福利！
https://developer.aliyun.com/article/1055629?groupCode=alitech?utm_content=g_1000361479
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
