这是一个创建于 1621 天前的主题，其中的信息可能已经有所发展或是发生改变。
希望参考下，做个模版。
 |
1
guyeu 2020-06-16 10:09:24 +08:00
基本上每个被广泛使用的 java 项目单测都很全。。。
|
 |
2
gzfrankie 2020-06-16 10:15:15 +08:00 via iPhone  1
Java 任意项目
Python Openstack Go Kubernetes |
 |
3
VDimos 2020-06-16 10:25:35 +08:00 via Android
rust 稍微大型点儿的项目继承和单元都做得不错
|
 |
4
hantsy 2020-06-16 10:33:48 +08:00
主流的 Java 框架都是基本上有写很全面的测试，Hibernate 系列，Spring 下各子项目。
|
|
5
hantsy 2020-06-16 10:41:03 +08:00
Java EE/Jakarta EE 测试起步有兴趣可以看看我的文章，https://medium.com/swlh/testing-jakarta-ee-8-applications-9ca250da20e3
Github 链接: https://github.com/hantsy/jakartaee8-starter/blob/master/docs/04test.md 当然我相信国内 90%开发人员都是从来不写测试的。 |
 |
6
hanxiV2EX 2020-06-16 12:38:11 +08:00
openresty
|
 |
8
ChanKc 2020-06-16 13:08:45 +08:00 via Android
openjdk
guava Apache commons 一般最主流最基础的工具包的都会全吧 |
 |
9
williamfzc 2020-06-16 13:09:11 +08:00
自己的 python，覆盖率到一定程度之后还是蛮有用的
https://github.com/williamfzc/stagesepx |
|
11
hantsy 2020-06-16 13:55:12 +08:00 4
@dilu 嗯，以前我在公司上班时候推过 JUnit，结果一半人明确反对，剩下的人反正没过用不知道行不行，没意见，结果都是不了了之。一个项目代码累积起来后，测试代码的作用就体现出来了，在 CI 上跑一遍的时候，几乎所有的场景都 replay 一遍，保证新加代码自己没问题，也不会桶了其它人的工作。之前为什么要想到用 JUnit，其主要原因也是这个，我的代码经常被报问题，结果 10 之 8，9 都是被别人捅了，破坏了一些约束。
现在国内一些开发人员，比如 API 的测试，很多愿意手动测试，用 PostMan，什么 Swagger 界面，只能片面的测试到一些问题，而且一直不停重复手动输入数据测试。我一直在想的一个问题，天天这样重复测试，自己不感觉烦吗？ 我一直认为 PostMan，Swagger 是给前端或者非技术测试人员（ UAT ）用的，在国内居然现在是开发人员的标配。 现在我也很矛盾，国内有些朋友介绍一些项目一看那个样子，我根本就不想介入。国外能做的项目，今年越来越少了，已经空好久了。 |
 |
12
littlewing 2020-06-16 13:56:55 +08:00 via iPhone
mysql
|
|
13
williamfzc 2020-06-16 14:13:01 +08:00
@hantsy 同意，单测大概率是推不动的，一般有这几个原因：
- 项目安排不会预留写单测的时间 - 一般都有测试兜底，做不做无所谓 - 自测 or 质量流程稀烂 基本是个恶性循环，除非项目愿意让步 or 有个比较有魄力的人来下决定。开源社区这类东西做得好一般也就是上面三点做得好： - 没项目压 - 没测试，自己兜底 - 流程相对严谨 比起单测，我觉得覆盖率反而是个比较值得推的东西。 |
 |
14
dayeye2006199 2020-06-16 14:24:04 +08:00
好像但凡正经点的开源项目，都有单元测试覆盖把。。啥也没有别人也不敢用把。。
|
 |
15
afc163 2020-06-16 14:27:14 +08:00
|
 |
16
dilu 2020-06-16 15:30:21 +08:00
|
 |
17
Rwing 2020-06-16 15:37:57 +08:00
所以需要 TDD
|
|
18
hantsy 2020-06-16 15:49:40 +08:00
@williamfzc 业务类型项目，cov 我觉得倒不是刻意去追求。比如 Spring 中，有些代码一开始可以从 coverage Excludes 掉，如 POJO （只有 Getter and Setters ），空的 Repository，一些 Configuration 等，一般测试能跑到 70，80% cov 还是很容易的。
1，主要要包含所有的可能的路径，比 /posts/{id} ，200 的返回结果与 404 都是要确认。要确认权限的有登录，未登录，切换 Role 等。 2，单元测试很多只是测试 Block 逻辑正确性，集成测试加上去，实际上很多测试部分重叠起来了。比例 PostController, 单纯的测试其逻辑功能可以在 Mock Web 环境跑，用 Mockito 之类的来隔离依赖（数据库等，其他调用）。https://github.com/hantsy/spring-reactive-jwt-sample/blob/master/src/test/java/com/example/demo/PostControllerTest.java，但同样的功能还是要跑一次集成测试确定所有功能在真实环境中有效： https://github.com/hantsy/spring-reactive-jwt-sample/blob/master/src/test/java/com/example/demo/IntegrationTests.java |
 |
19
KeyboardManAnAn 2020-06-16 17:50:45 +08:00 via iPhone
Realm 移动端数据库测试覆盖比较全
|
 |
20
asanelder 2020-06-16 18:31:34 +08:00
@hantsy 干公司的活，如果自己不是 leader 或是有什么话语权的话，还是随大流吧。
虽然单元测试俺认为很重要，但是如果 leader 和其它人认为不重要，那就是不重要了。 在公司工作，就要和组内的同志以及 leader 保持观念上的一致，无论这个观念你认不认同。 |
|
21
asanelder 2020-06-16 18:33:12 +08:00
@hantsy 俺在国内一下大厂的某部门待过，RD 真的是基本不写测试的（无论是不是业务逻辑），看兄台是在国外干过？国外这方面要好一些么？
|
 |
22
lenqu 2020-06-16 18:51:06 +08:00
我个人认为现在的单元测试 IDE 插件没有参数化的那种，如果有，写单元测试就没那么多时间消耗，而且对于项目是有益的，何乐而不为呢，主要原因是项目压太短，多一事不如少一事。
|
|
23
hantsy 2020-06-16 21:08:39 +08:00
@asanelder 没有。
现在 Freelancer 多年，只接海外项目。国外绝大部分都要求写测试，有些项目明确要求，如果你没有写测试同等没完成交付。 我对测试要求只能算是一般。 1. 开发一定要写测试。不要求写测试的项目，特别是多人合作的，我不谈的。以前国内的滥泥一样开发过程让我明白，在多人协作环境下，写测试是必不可少的，不然你一天的工作 70%时间都是为一些比较渣的人擦屁股。 2. 但是不一定严格的执行 TDD, 我大部分时间是后写测试。 3. 我个人不要求 100% COV，但必须覆盖所有的业务路径，业务上的正常和异常路径，各权限都是必须用测试体现出来。 遇到过一些比较偏执的，以前一个项目本来 API 开发，用 Spring 的话自带测试工具已经可以应付。老外坚持要用 JBehave 进行 BDD 测试，费了好多力才让他接受 RestAssured （同样支持 BDD 类似的语法），当然如果是现在，我觉得 Spock 更好一些。 |
 |
24
fuyufjh 2020-06-16 21:16:39 +08:00
居然没人说 SQLite ？ 14 万行代码，9000 万测试代码，100%分支覆盖率。再加上各种丧心病狂的随机测试和故障注入
|
 |
25
death00 2020-06-16 22:02:15 +08:00 1
入职一个大厂半年多，之前还会写一些，最近也不怎么写 UT 了。
虽然公司也要求写 UT，但在各个组内推行的比较慢。 感觉有这么几点： 1 、因为之前就没有写，对于陌生的事务，大家本能的有一种抗拒。 2 、写 UT 需要时间。每次一个需求过来，虽然排期比较宽松，但每天肯定也会处理各种各样的问题，因此开发时间也不够用。 3 、效果收益（ KPI ）。我感觉这个是最重要的，如果没有产生明显收益，很多人也是不会去做的。无论是你的领导还是你的组员，都背着相应的 KPI，如果没有收益，怎么汇报成果，这个可能也要和制度有一定关系。 4 、项目未来不一定是自己维护。现在大家跳槽频繁，很多项目虽然会持续很长时间，但后面不一定是自己维护，所以短期内的质量，大家感觉可以自己保障。（吐槽一点，很多连注释都没有的代码，就更不敢奢谈 UT 了） |
 |
26
CoderGeek 2020-06-16 22:49:51 +08:00
高级脚手架 很全面
|
|
28
hantsy 2020-06-16 23:01:50 +08:00 1
@death00 我可以忍受代码没有注释，前提你写的是代码（类名，包名，方法名，参数名自身能够 Self Documentation ），但绝对不能忍受代码没有写测试。
测试不在项目一开始引入 ，基本后面是不可能再引入 ，人的惰性很难改变。一旦形成了惯性思维，几乎很难接受其他理论和实践。国内唯一可以有效的方法就是把测试纳入绩效，挠痒痒式的要求写测试肯定没人执行啦。 很人认为写测试仅仅测试代码逻辑正确性。其实嘛 ，当你写测试的过程，很多的时候是以 API Caller 身份在调用你的写的程序，最初设计的不合理的 API，在测试的调用也不方便，所以写测试（和不断重构）的过程也是一个代码优化（构架提升）的过程。 我从来不认为国内的大厂在软件工程方面有什么值得加分地方或者建树，相反一些非常恶劣的做法都引起其他公司的效仿，国内有少量注重 Engineering 基本都是小公司，开发一些小产品。 |
|
30
asanelder 2020-06-17 00:41:40 +08:00 2
@hantsy #28 强烈认同
1. 注释是说明意图的，能够 self documentation 最好，不能的一定要说明意图（俺看之前的遗留代码各种魔幻，可惜人已离职，你也不知道为啥添加这一段代码，改是绝对不敢碰的 2. 俺也觉得测试三大作用。一是明确验证程序行为，二是给你信心进行重构，三是站在使用者和易测试角度去设计 api，得到的 api 往往更灵活，更有好。还有一点，测试也可以做某种意义上的文档，后人来维护时，看你测试，能看到这个 api 如何使用，以及行为是什么。 3. 俺工作以前以为大厂为重视这些，但起码在俺呆过的大厂的某个组是完全不 care 的，是的，完全不 care，测试这种东西全交给 QA，RD 从不提这些。 4. 俺很后悔在学校看了一些什么软件质量的洗脑书，如果不知道这些的话，俺做牛做马，心里应该舒服很多。可现在不行了，心里还是过不了这个砍 |
 |
31
js8510 2020-06-17 08:53:25 +08:00
据说 chrome 的覆盖 100%. 另外所有 c++ sanitizer(ASAN, UBSAN, etc) 全开。求 googler 证实。chromium 也很高，核心部分 80% 左右 https://analysis.chromium.org/p/chromium/coverage
|
 |
32
Egfly 2020-06-17 09:15:21 +08:00
有没有 PHP 的开源项目，单元测试覆盖比较全面的
|
|
33
hantsy 2020-06-17 10:14:56 +08:00 1
@Egfly 多的是啊，PHP 近几年都是延袭 Java 的一套风格，特别 5.6 后，PHP 的 OOP 基本与 C#，Java 在一条线上了。很多 Java 产品都是在 PHP 世界开始 Clone, 这些优秀的框架都有完整的测试。
Java 的 Spring，EIP 在 Symfony，ZendFramework （现在改名了，一直记不住新名字，现在是 Linux 基金下的一个项目了）得到体现。 Hibernate 和 Hibernate Validator 都是 Doctrine 上克隆了。 JUnit 本身也有 PHPUnit Clone. |
 |
34
warcraft1236 2020-06-17 14:44:36 +08:00
问个问题，如果是爬虫项目，单测都需要做啥呢？
|
|
35
death00 2020-06-20 11:47:34 +08:00
@hantsy
你的说法我也很认同，但对于"国内唯一可以有效的方法就是把测试纳入绩效"这点，我感觉实行起来或许有些困难。 因为如果作为绩效考核点，一定要有明确的标准和定义，这个培训成本预估也会挺大的，需要公司有决心和能力。 |
|
37
hantsy 2020-06-20 12:12:37 +08:00
@death00 只是说说，开玩笑而已。不是别的，国内外程序员对待工作差别太大了，国内公司上班员工基本上是认同家长命令式的管理，上面怎么说就怎么做，感觉错与对的结果与他没太大的关系，当然我一直认为这是跟我们大环境有很大关系。
上层没有发话的很少人在一些事情上有自己的主见，往不好听说，有一半人上班是磨子一样，推一下转一下，有那么 10%的人连磨子都不是，怎么都推不转（这个话我前几年在创业公司说过的）。 而参与在国外的项目一些讨论才知道什么叫扁平管理，每周例会，一些要做的任务经过简单的讨论，很多都是自己认领，很少 Assign 。 |
Select Language