各位大佬项目里写单元测试了吗？

[magic3584]

自己写了一个 app ，总是担心自己手动测试覆盖度不够会导致崩溃，所以一开始就接了 firebase 。 看了下近一个月崩溃为 0 ，当然也是因为日活接近 0😂

每次发版前也会点点点好久，功能复测好几种情况，但仍然在发布后会发现一些别的小问题。。。

看某位大佬说他自己的项目，跑测试都要跑很久。之前工作中也从来没写过单元测试、集成测试等，现在也在看一些 flutter 的单元测试教程。bug 不可怕，就怕崩溃再也打不开 app ，修复都无法修复的那种。

所以各位大佬会写一些单元测试集成测试吗？

[Philippa]

需要频繁迭代的写，除了给自己看，更多是给别人跑的。别人加了新代码，防止影响了自己的功能。我自己的一般不写，包括交易程序…. 但每次执行之前都会先跑一系列检查。你一开始紧张没啥，实验多了你自然知道平衡点在哪里，该严谨严谨，该偷懒偷懒。单测跑很久不一定是很严谨很多，也可能只是很慢很多细节….

[Philippa]

有个老程序屎山，很多单元测试，都是多台机器并行跑的，也要快一小时。我实在无法说这项目质量好。另外，单元测试很费时间，很多时候不过也是因为单元测试的 bug 而不是代码的 bug

[magic3584]

@Philippa #1
您说的这个“一系列检查”指的是什么？
目前发更了几个版本，就发现之前写的代码有点丑了，但是后面还有好多需求要做，也抽不出时间去重构。但是总放着也不是事，要不然后面就成屎山了。。。所以现在想学一点怎么写，最起码容易引起崩溃和逻辑重的地方得跑一下

[GooMS]

项目规模大了就测试了，你也不想每次发包都要紧急修吧

[Philippa]

@magic3584 跑前一般不做功能测试，但会做状态检查。程序就是一个 state 到另一个 state 。比如链接、账户、api 连接性、数据是否最新等等。因为假如 state 出现问题，虽然不知道为什么，但能知道程序出问题不能继续。因为单元测试是写不完的，所以比较效率的方法是把最重要的地方覆盖了，即使出事最多就是程序崩了，不至于数据或状态出现问题。屎山很多时候是受制于团队，还有时间以及管理的，很难一个人控制。另外我觉得后端最基本的是数据准确和一致性，速度和稳定性都是可以后面弥补或通过其他手段提升。但数据一旦出现问题基本上很难弥补，所以我把单元测试重心都放在数据方面的检查。

[hxndg]

我现在写 UT & IT 基本都成为习惯了，UT 一般要 cover 关键的基础函数，后期如果出现问题了，可以写 IT 去 Cover 。

为啥需要写 UT ？因为 UT 很多时候会帮你发现很多隐喻是错误的，这些东西能够保证你基础的正确，我靠 UT 查出来过线上环境的问题（记到了博客里面），

至于 UT 怎么写，这个是看你的函数设计能力，不过理论上是在写代码之前就确定怎么写 UT 比较合适，这就是 UT 的另一个好处了，你的函数逻辑层次好了，才能用 UT cover 住

[magic3584]

@GooMS #4
@Philippa #5
@hxndg #6

刚才我以为这个 feature 完成了，又发现保存以后退出再进去修改，再保存的时候就出错了。。。虽然不会崩溃，但是通知提醒的时间会延迟，这肯定不能接受，如果提前的话还好。。。

我刚接触单元测试，还不太会写，并且先有测试思路再去写代码。请问有一些比较好的教程吗？我目前是在 youtube 上看的 flutter 的。

另求大佬 @hxndg 博客看能否学到点什么。

[hxndg]

@magic3584
额，不用看我的博客，毕竟我本身不做 flutter ，本身技术栈是 c/c++/go/，你确定好代码结构就成。看看程序员修炼之道，clean code ，clean arthich 啥的就成