业务代码写单元测试的最佳姿势是什么？

@XiLemon 我发现我笔误了，是会 fail 的测试而不是单测。不一定是单测，而且通常来说它的需求是解析某网址，显然不应该是单测。

不过我凭空推测，它估计不是因为 TDD，而是因为 Issues 被广告机爆了。

用来调试 API

补充一下 #40，其实还有很关键的一点：很多人业务代码没有能力写干净，写测试代码就一定会更加添乱，这种人写测试往往都会半途而废。

楼上老哥有几个写单元测试的？
业务的变动和要求，你根本没时间写
也就面试的时候会被问到
理想和现实的差距

首先自身业务代码层次要清晰，各层级间耦合度要低，这样在 Mock 的时候工作量才会少，才能专注测试的内容，不然光写 Mock 就一堆代码。
在一个 Service 方法里调用另外 3 、4 个 Service，然后又调用几次 Dao 不同的方法这种流水帐一样的代码写 Mock 都要写死人，怎么让人写单元测试。

业务代码不写单元测试。你是嫌加班不够多，还是工作不饱和？

单元测试有两个大前提：

一、你不一定要 TDD （先写测试代码），但测试框架的设计一定要早于主代码框架的——单元测试是领导而不是擦屁股的。

二、不一定是大项目，但一定是长期或者计划长期维护的项目——非自动化需要大量执行成本 /自动化需要大量设计成本，你不该为了半年甚至一天后就抛弃的项目做单元测试。

@ClericPy 我这边业务不是太复杂, 有时候单元测试有时候简单的功能测试, 太细致的单元测试就连 TDD 那本书作者都不建议 ( https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests , 也就是著名的那句 "I get paid for code that works, not for tests")

有的同事天天加班到十一点, 进度天天催, 根本没时间写完整测试, 连文档都不愿意看, 最后布一套测试环境跑通核心功能验收就上线了. 毕竟对绝大多数公司来说, 开发人力根本严重不足, 方法论什么的行不通

总结起来就是, 上线前一定要有测试, 但是不要迷信 100% coverage.

我一般只写集成测试，数据库也不 mock，直接去读，这种方法很少有人提倡，但是在实际的业务开发中是性价比最高的，既省时间又能保证程序的基本功能。传统测试理念要求一个功能写一个单元测试，甚至写功能之前就要写测试，比如 TDD，这样做得话听起来很不错，但是实际开发中根本跟不上需求的进度

@lightjiao 有时一个类会依赖十几个对象, 那这个构造函数就够大的了, 你还能区分构造函数里哪个参数是哪个吗

单测非常有必要，单测也是某种意义上的代码文档，在接手别人代码和重构时候就会知道单测意义所在了

@qwerthhusn 好奇问下，怎么方法能把测试覆盖率提高到将近 100%？

我司要求单侧覆盖超过 80%，代码才允许合并，所以慢慢变成为了写好单元测试而写代码，大部分时间都在写单元测试

小型工具方法写单测，业务逻辑写集成测试。
业务逻辑写集成测试，mock 掉外部依赖（外部接口一类的），数据库不 mock，可以看下 testcontainers 项目，在测试部分启 MySQL / Redis 等容器。

@witcherhope
@ljf 两位老哥、分享一波经验呀
@lix7 多谢

从一些简单逻辑开始呗：
1. 比如 API 的输入 check
2. 比如相对简单但是共用的 util

一般来说，你觉得 test 不知道怎么写，要么是代码实在写的有问题，要么就是本身就不该写，不过大部分不知道怎么写都是代码的问题，可能层次划分的不对，逻辑拆分的不够细等等

一年过去了，楼主单元测试有值得方向的经验吗

@MarioLuo #57 并没有，依然在裸奔

@lix7 赞同