这是一个创建于 341 天前的主题，其中的信息可能已经有所发展或是发生改变。
自己写了一个 app ，总是担心自己手动测试覆盖度不够会导致崩溃，所以一开始就接了 firebase 。 看了下近一个月崩溃为 0 ，当然也是因为日活接近 0😂
每次发版前也会点点点好久，功能复测好几种情况，但仍然在发布后会发现一些别的小问题。。。
看某位大佬说他自己的项目，跑测试都要跑很久。之前工作中也从来没写过单元测试、集成测试等，现在也在看一些 flutter 的单元测试教程。bug 不可怕，就怕崩溃再也打不开 app ，修复都无法修复的那种。
所以各位大佬会写一些单元测试集成测试吗？
 |
1
Philippa 341 天前 via iPhone
需要频繁迭代的写，除了给自己看，更多是给别人跑的。别人加了新代码，防止影响了自己的功能。我自己的一般不写，包括交易程序…. 但每次执行之前都会先跑一系列检查。你一开始紧张没啥，实验多了你自然知道平衡点在哪里，该严谨严谨，该偷懒偷懒。单测跑很久不一定是很严谨很多，也可能只是很慢很多细节….
|
|
2
Philippa 341 天前 via iPhone
有个老程序屎山，很多单元测试，都是多台机器并行跑的，也要快一小时。我实在无法说这项目质量好。另外，单元测试很费时间，很多时候不过也是因为单元测试的 bug 而不是代码的 bug
|
 |
3
magic3584 OP @Philippa #1
您说的这个“一系列检查”指的是什么？ 目前发更了几个版本，就发现之前写的代码有点丑了，但是后面还有好多需求要做，也抽不出时间去重构。但是总放着也不是事，要不然后面就成屎山了。。。所以现在想学一点怎么写，最起码容易引起崩溃和逻辑重的地方得跑一下 |
 |
4
GooMS 341 天前 via Android
项目规模大了就测试了，你也不想每次发包都要紧急修吧
|
|
5
Philippa 341 天前 via iPhone
@magic3584 跑前一般不做功能测试，但会做状态检查。程序就是一个 state 到另一个 state 。比如链接、账户、api 连接性、数据是否最新等等。因为假如 state 出现问题，虽然不知道为什么，但能知道程序出问题不能继续。因为单元测试是写不完的，所以比较效率的方法是把最重要的地方覆盖了，即使出事最多就是程序崩了，不至于数据或状态出现问题。屎山很多时候是受制于团队，还有时间以及管理的，很难一个人控制。另外我觉得后端最基本的是数据准确和一致性，速度和稳定性都是可以后面弥补或通过其他手段提升。但数据一旦出现问题基本上很难弥补，所以我把单元测试重心都放在数据方面的检查。
|
 |
6
hxndg 341 天前
我现在写 UT & IT 基本都成为习惯了，UT 一般要 cover 关键的基础函数，后期如果出现问题了，可以写 IT 去 Cover 。
为啥需要写 UT ？因为 UT 很多时候会帮你发现很多隐喻是错误的，这些东西能够保证你基础的正确，我靠 UT 查出来过线上环境的问题（记到了博客里面）， 至于 UT 怎么写，这个是看你的函数设计能力，不过理论上是在写代码之前就确定怎么写 UT 比较合适，这就是 UT 的另一个好处了，你的函数逻辑层次好了，才能用 UT cover 住 |
|
7
magic3584 OP |
Select Language