- “123” → 123
- null或空字符串 → null
- " 123"、" 123 "、"123 "、"1 23 "、"1 2 3 “、” 1 2 3 " → 123
- “123a”、“1*23”、“abc” → null
- “1234567890” → 1234567890
用例设计更多考验程序员思维的缜密程度，看能否设计出覆盖各种正常/异常情况的测试用例，来保证代码在任何预期或非预期情况下都能正确运行。写完用例，接着就是将其翻译成带么了(此处没用任何测试框架)
// 结果校验类
public class Assert {
public static void assertEquals(Integer expectedValue, Integer actualValue) {
if (actualValue.intValue() != expectedValue.intValue()) {
System.out.println(String.format(“测试失败：期待值：%d，实际值: %d”, expectedValue, actualValue));
} else {
System.out.println(“测试成功”);
}
}
public static boolean assertNull(Integer actualValue) {
boolean isNull = actualValue == null;
if (isNull) {
System.out.println(“测试成功”);
} else {
System.out.println(“测试失败，实际值不为null：” + actualValue);
}
return isNull;
}
}
// 测试用例类
public class TextTest {
public void testToNumber() {
Assert.assertEquals(123, new Text(“123”).toInt());
}
public void testToNumber_nullOrEmpty() {
Assert.assertNull(null);
Assert.assertNull(new Text(“”).toInt());
}
public void testToNumber_containsSpace() {
Assert.assertEquals(123, new Text(" 123").toInt());
Assert.assertEquals(123, new Text(" 123 ").toInt());
Assert.assertEquals(123, new Text("123 ").toInt());
Assert.assertEquals(123, new Text("1 23 ").toInt());
Assert.assertEquals(123, new Text("1 2 3 “).toInt());
Assert.assertEquals(123, new Text(” 1 2 3 ").toInt());
}
public void testToNumber_containsInvalidCharacters() {
Assert.assertNull(new Text(“123a”).toInt());
Assert.assertNull(new Text(“1*23”).toInt());
Assert.assertNull(new Text(“abc”).toInt());
}
public void testToNumber_large() {
Assert.assertEquals(Integer.MAX_VALUE, new Text(“” + Integer.MAX_VALUE).toInt());
}
}
// 运行用例类
public class TestCaseRunner {
public static void main(String[] args) {
TextTest test = new TextTest();
test.testToNumber();
test.testToNumber_nullOrEmpty();
test.testToNumber_containsSpace();
test.testToNumber_containsInvalidCharacters();
test.testToNumber_large();
}
}
测试结果如下：
从上面的示例我们可以总结出：写单元测试就是针对代码设计覆盖各种输入、异常、边界条件的测试用例，用将用例翻译成代码的过程。
另外，翻译代码时，可利用单元测试框架(如JUnit、TESTNGINX、Spring Test等) 来简化测试代码的额编写。
③ 为什么要写单元测试
- 帮你发现代码中的BUG (节省fix低级bug的时间，写出Bug Free代码是判断工程师编码能力的重要标准之一)；
- 帮你发现代码设计上的问题 (代码的可测试性是评判代码质量的重要标准，难写单元测试一般说明代码设计可能有问题);
- 单元测试是对集成测试的有力补充 (复杂系统，集成测试也无法覆盖得很全面);
- 写单元测试的过程本身就是代码重构的过程；
- 阅读单元测试能帮助你快速熟悉代码(单元测试案例实际上就是用户案例，反映了代码的功能及使用，在没有文档或注释的情况下，它可以起替代性作用，借助单元测试案例，无需深入阅读代码，即可了解代码实现了什么功能);
- 单元测试是TDD可落地执行的改进方案 (Test Driven Development，测试驱动开发，测试用例优于代码编写)；
④ 编写单元测试的经验总结
写单元测试真的是件耗时的事吗？
代码量多，写的过程繁琐，但并不是很耗时，因为不用考虑太多代码设计上的问题，大部分是cv操作。
对单元测试的代码质量有什么要求吗？
单元测试毕竟不会在生产环境运行，类的测试代码都相对独立，代码质量要求可以放低些，命名不是很规范、代码重复有些重复，也是可以的。
单元测试只要覆盖率高就够了吗？
测试覆盖率是比较容易量化的指标，常常作为单元测试写得好坏的评判标准。有很多现成的工具专门用来做覆盖率统计(如JaCoCo、Cobertura等)。覆盖率的计算方式也有很多种，最简单的语句覆盖、稍微高级点的：条件覆盖、判定覆盖、路径覆盖。
盲目追求高覆盖率是不可取的，更重要的是看测试用例是否覆盖了所有可能的情况，特别是一些边界条件。
过度关注覆盖率会导致开发人员为了提高覆盖率，写了很多没必要的测试代码(如get、set)。从过往经验来讲，一个项目的单元测试覆盖率在60~70%即可上线，当然如果项目对代码质量要求严格，亦可适当提高覆盖率要求。
写单元测试需要了解代码的实现逻辑吗？
不需要，单元测试只关心被测函数实现了什么功能，切不可为了追求覆盖率，逐行阅读代码，然后针对实现逻辑编写单元测试。
如何选择单元测试框架？
团队内部统一即可，自己写的代码用已选定的单元测试框架无法测试，多半是代码写的不够好，可测试性差，这个时候要重构自己的代码，使其更易测试，而不是找另一个更加高级的单元测试框架。
单元测试为何难落地执行？
- 写单元测试本身较繁琐，技术挑战不大，很多程序员不愿意去写；
- 国内研发比较偏向"快、糙、猛"，容易因为开发进度紧，导致单元测试执行的虎头蛇尾；
- 团队成员没有建立对单元测试的正确认识，觉得可有可无，单靠督促很难执行得很好；
0x3、代码的可测试性
代码的可测试性，粗略地讲就是：针对代码编写单元测试的难易程度，对于一段代码很难为其编写单元测试，或者写起来很费劲，需要依赖单元测试框架中很高级的特性，那么往往意味着代码设计不够合理，代码的可测试性不高。
如果代码中依赖了外部系统或不可控组件(如数据库、网络通信、文件系统等)，就需要将被测代码与外部系统解依赖，这种解依赖的方法称作 “Mock”，即用一个 “假” 的服务替代真正的服务，Mock服务在我们的控制下，模拟输出我们想要的数据。Mock方式又分两种，手动和使用框架Mock。
常见的测试不友好的代码有这几种：
- 代码中包含未决行为逻辑 (输入随机或不确定，如时间、随机数相关代码，应将其抽取到到方法中，方便测试替换)
- 滥用可变全局变量 (测试用例可能相互影响)；
- 滥用静态方法 (同上，还有静态方法可能不好Mock)
- 使用复杂的继承关系 (父类需要mock某个依赖对象才能进行单元测试，所有子类都要mock这个依赖对象);
- 高度耦合的代码 (一个类要依赖十几个外部对象才能完成工作，单元测试时可能要mock这十几个依赖的对象);
0x4、如何通过封装、抽象、模块化、中间层等解耦代码
① 解耦为何如此重要？
- 重构 是保证 代码质量 不至于腐化到无可救药的有效手段；
- 解耦 则是对代码重构，保证代码不至于 复杂 到无法控制的有效手段；
“高内聚、低耦合” 的特性可以让我们聚焦在某一模块或类中，而不需要了解太多其他模块或类的代码，让焦点不过于分散，降低阅读和修改代码的难度。依赖关系简单，耦合小，修改代码也不至于牵一发而动全身，代码改动集中，引入bug的风险也少了，而且可测试性更佳，容易Mock或只需Mock少量外部依赖。
② 如何判断代码是否需要解耦
除了看改代码会不会牵一发动全身外，还可以把 模块间、类与类间的依赖关系画出来，根据依赖关系图的复杂性来判断是否需要解耦重构。如果依赖关系复杂混乱，那从代码结构上讲，可读性和可维护性肯定不是太好。
③ 如何给代码解耦？
- 封装与抽象 (隐藏复杂性，隔离变化，对外提供稳定易用接口)；
- 中间层 (简化模块或类之间的依赖关系)；
- 模块化 (模块只提供封装了内部实现细节的借口给其它模块使用，以此减少不同模块间的耦合度);
- 其他设计思想和原则 (单一职责、基于接口而非实现编程、依赖注入、多用组合少用继承，迪米特法则);
0x5、最快速改善代码质量的20条编程规范
① 命名
- 命名长短 → 以能
准确达意为目标，在能达意的情况下越短越好，默认或大家都熟知的词，推荐用缩写； - 利用上下文简写命名 → 作用域较小的临时变量、借助类这个上下文成员变量和函数参数，可以简化命名(如User类中的name)；
- 命名要可读、可搜索 → 不要用生僻、难发音的单词来命名，统一命名习惯(如都用selectXXX表查询，你就不要用queryXXX)；
- 接口和抽象类命名 → 接口前缀加"I" 或后缀加Impl，抽象类加或不加前缀Abstract，选择哪种命名方式都可以，但是要在项目里统一！
② 注释
注释到底该写什么？(做什么、为什么、怎么做)，代码示例如下：
/**
- (what) Bean factory to create beans.
- (why) The class likes Spring IOC framework, but is more lightweight.
- (how) Create objects from different sources sequentially:
- user specified object > SPI > configuration > default object.
*/
public class BeansFactory {
// …
}
尽管做什么、怎么做可以从代码中体现出来，但是还是建议在注释中写明，原因如下：
- 注释比代码承载的信息更多 → 类包含信息较多，简单的命名可能不够详尽，在注释中写明做什么更便于阅读；
- 注释起到总结性、文档的作用 → 让阅读代码的人通过注释就能大概理解代码的实现思路；
- 一些总结性注释能让代码结构更清晰 → 逻辑较复杂、较长又不好提炼拆分的函数，借助总结性注释让代码结构更清晰；
当然，不是注释写得越多就越好，太多意味着代码写得不够刻度，而且会对代码本身的阅读造成干扰，后面维护成本也较高。
一般来说：类和函数一定要写注释，且尽可能全面、详细，而函数内部的注释要相对少一些，一般都是靠好的明明、提炼函数、解释性变量、总结性注释来提高代码的可读性。
③ 代码风格 (团队/项目统一)
类、函数多大才合适？
很难给出一个确切的值，一个间接的判断标准：当一个类代码读起来让你感觉头大、找个函数找半天、用一个小功能就要引入整个类(类中包含很多无关此功能的实现函数)时，就说明类的函数过多了。
一行代码多长最合适？
一行代码最长不能超过IDE显示的宽度，滚动鼠标才能查看一行的完整代码，显然不利于代码的阅读。
善用空行分割单元块
对于较长、又不方便抽取成小函数的函数，除了用总结性注释分隔外，还可以用空行来分割代码块。除此之外，类成员与函数间、静态成员变量和普通成员变量间、各函数间等，都可以通过添加空行的方式让其界限更加明确。
四格缩进还是两格缩进？
都可以，但项目内要统一，建议不要使用Tab缩进，因为不同IDE的Tab缩进显示宽度不同，要用也行，要统一配置好！
大括号是否要另起一行？
都可以，推荐括号与语句同一行，这样可以节省代码行数，另起一行也行，左右括号垂直对齐，可以方便的看到哪些代码属于哪个代码块，各有千秋，还是那句话项目统一。
类中成员的排列顺序
建议：类所属包名 → import引入的依赖类(字母序从小到大排列) → 成员变量 → 函数，变量和函数间都是按照先静态后普通，作用域范围从大到小排列。实际上，还有种排列习惯，就是将有调用关系的函数放到一块。
④ 编程技巧
将代码分割成更小的单元块
当代码逻辑较复杂时，才建议提炼类或函数，如果提炼出的函数只包含两三行代码，阅读代码时还得跳过去看，反而增加了阅读成本。
避免函数参数过多
参数大于等于5个时，会影响到代码的可行，用起来也不方便，先考虑是否职责单一拆解，或者将函数的参数封装成对象传递。
勿用函数参数来控制逻辑
不要在函数中使用boolean类型的标识来控制内部逻辑，ture走这块逻辑，false走另一块，这违背了单一职责和接口隔离原则，建议拆成两个函数。还有一种判断参数是否为null控制逻辑的情况，同样建议拆解。
函数设计要职责单一
函数设置将更要满足单一职责原则，能多单一就多单一。
移除过深的嵌套层次
过深的嵌套本身理解起来比较费劲，嵌套超两层就要思考是否能减少嵌套，几种解决思路：
去掉多余的if或 else语句、使用编程语言提供的continue、break、return关键字提前退出嵌套、调整执行顺序、将部分逻辑封装成函数调用，多态等。
学会使用解释性变量
常量取代魔法数字，使用解释性变量来解释复杂表达式，示例如下：
public double CalculateCircularArea(double radius) {
return (3.1415) * radius * radius;
}
// 常量替代魔法数字
public static final Double PI = 3.1415;
public double CalculateCircularArea(double radius) {
return PI * radius * radius;
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）
《设计思想解读开源框架》
第一章、 热修复设计
-
第一节、 AOT/JIT & dexopt 与 dex2oat
-
第二节、 热修复设计之 CLASS_ISPREVERIFIED 问题
-
第三节、热修复设计之热修复原理
-
第四节、Tinker 的集成与使用（自动补丁包生成）
第二章、 插件化框架设计
-
第一节、 Class 文件与 Dex 文件的结构解读
-
第二节、 Android 资源加载机制详解
-
第三节、 四大组件调用原理
-
第四节、 so 文件加载机制
-
第五节、 Android 系统服务实现原理
第三章、 组件化框架设计
-
第一节、阿里巴巴开源路由框——ARouter 原理分析
-
第二节、APT 编译时期自动生成代码&动态类加载
-
第三节、 Java SPI 机制
-
第四节、 AOP&IOC
-
第五节、 手写组件化架构
第四章、图片加载框架
-
第一节、图片加载框架选型
-
第二节、Glide 原理分析
-
第三节、手写图片加载框架实战
第五章、网络访问框架设计
-
第一节、网络通信必备基础
-
第二节、OkHttp 源码解读
-
第三节、Retrofit 源码解析
第六章、 RXJava 响应式编程框架设计
-
第一节、链式调用
-
第二节、 扩展的观察者模式
-
第三节、事件变换设计
-
第四节、Scheduler 线程控制
第七章、 IOC 架构设计
-
第一节、 依赖注入与控制反转
-
第二节、ButterKnife 原理上篇、中篇、下篇
-
第三节、Dagger 架构设计核心解密
第八章、 Android 架构组件 Jetpack
-
第一节、 LiveData 原理
-
第二节、 Navigation 如何解决 tabLayout 问题
-
第三节、 ViewModel 如何感知 View 生命周期及内核原理
-
第四节、 Room 架构方式方法
-
第五节、 dataBinding 为什么能够支持 MVVM
-
第六节、 WorkManager 内核揭秘
-
第七节、 Lifecycles 生命周期
本文包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等，资源持续更新中…
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
知 View 生命周期及内核原理**
-
第四节、 Room 架构方式方法
-
第五节、 dataBinding 为什么能够支持 MVVM
-
第六节、 WorkManager 内核揭秘
-
第七节、 Lifecycles 生命周期
[外链图片转存中…(img-NQCVSkt2-1713621790084)]
本文包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等，资源持续更新中…
[外链图片转存中…(img-pbQV4Ovy-1713621790085)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
247
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
