@PixelMage sorry，我看了前半句没看后半句，误解了你的意思。

感觉我们的讨论有点跑偏，e2e 测试和单元测试其实是处在不同维度，解决的具体问题是不一样的，不能用来直接比较，不是一个非零即一的问题。

单元测试是验证代码逻辑问题，而不是验证业务逻辑问题。
相反，e2e 测试只能保证业务逻辑正确，但无法保证代码或软件是健壮的。（或者需要很大代价）

@PixelMage 要找 repo 的话，可以上 github 上找，我看得比较多是 dgraph 和 k8s 的 repo （跟工作有关）。
哦对了，我是 Gopher，Java 不是很熟，不过根据经验，标准库里面的例子就足够学了，我相信 Java 的标准库应该也有单元测试的。

关于你最后一点“但是在日常的业务系统开发中，而不是伟大软件开发中，经常会出现为了开发速度牺牲质量的 tradeoff”，我想还是分享一下我的经历。（这里的质量，我理解的是程序是否有 bug，而不是代码优不优雅的问题）

其实刚开始我们也是觉得写单元测试浪费时间，如果把开发活动框在从研发到打包这段过程的话，单元测试的确是影响了开发进度的。但是如果你把软件的发布，运营，bug 反馈，定位，修复，再发布这些环节考虑进来，你会崩溃掉的。

“为了开发速度牺牲质量”，其实到了最后我们发现这是个伪命题来的，因为软件质量是第一位的。如果软件万一真的有 bug，即使不考虑业务损失，当这个 bug 出现的时候，你需要马上放下手上正在开发的特性，去排查定位，重建环境，代码修复，测试，打包，发布等，这一系列的工作牵扯到的不只是写出这个 bug 的那一位研发人员，而是牵扯到运维，测试等一系列人员。将人力成本，时间成本，沟通成本等考虑进来之后，其实整个团队的研发效能非常低的。

当然，如果一个研发人员和一个测试人员合作无间，测试能够在出现 bug 的时候，就直接告诉研发人员是哪个模块甚至哪一行出问题了，这种分工也是没问题的，但是我没见过。语言沟通有效率本来就够低了，更何况现在研发和测试都不在一个办公室里，用 IM 发着文字沟通，又或者在看板上发评论来沟通 bug。

“为了开发速度牺牲质量”这种观念很普遍，我猜是因为大部分研发人员都是个体在工作，容易把自己的职责框在写代码到代码提交之间。但当你开始关心整个研发团队的效能上时，你很容易发现问题。

@PixelMage 你这句话从理论上说没错，但实际上，你要 e2e 测试覆盖所有业务逻辑几乎不可能。

而且服务程序还要考虑 failure 的情况吧，例如下游服务无响应，响应超时，例如数据库连接失败，查询失败等情况。如果要在 e2e 测试中完成，你还要部署这样的环境出来，而用单元测试的话就可以轻松覆盖这些异常情况了。

回到你的问题：
“在 e2e 测试覆盖了所有业务逻辑的情况下，” ——业务逻辑覆盖是否有可量化指标，如何证明你覆盖了“所有”的业务逻辑呢？
“出于对业务系统稳定性的考虑，而不是代码逻辑优化的考虑下，”——系统稳定并不只有业务逻辑，还有其他异常情况考虑
“是否还有必要再写单测？”——单元测试只是一种软件质量保证的手段，而且经过多年的考验，看看那些著名的开源软件有没有写单元测试。如果你觉得你比那些牛人聪明，你有比单元测试更好的手段去保障软件质量，你可以选择你的方法。

@lihongjie0209 凡是人手写的代码都需要写单元测试，只要是个函数都可以写单元测试。实践过程里可能比较棘手的是如何 mock 了。刚开始的时候挺痛苦的，现在基本不会出现无法写单元测试的情况（除了要往老代码里加特性）。

@lolizeppelin #8
对，写久了单元测试，就会有这样的感觉：
如果发现单元测试比较难写，就会考虑我的代码设计是不是有问题

@lihongjie0209 #3
1. 每开发一个特性，就从主干拉出特性分支
2. 开发完并加上单元测试，就提 MR
3. MR 触发流水线，跑单元测试，计算代码行覆盖率，不达标就不通过
4. 流水线跑通过后，才能合并回主干

PS：关于特性，这里不是产品特性，更多是研发角度的特性，例如加个函数，加一个类等。我们一般趋向于把产品特性切分成多个更细的开发特性，这样可以确保分支不会离开主干太久。
PPS：关于单元测试的有效性，执行层面上，只有代码覆盖率这一个可量化指标，而单元测试有效性只能靠自觉了（ assert 的编写其实很影响单元测试的有效性的），例如一旦被发现“作弊”，就会被开除。

不知道这是不是你想问的……

如果你能确保你的接口测试用例，能够覆盖代码中所有可能的条件分支，那当然是最好的了。
然而现实问题是，编写有效的接口测试比编写有效的单元测试成本更高。
我这边的做法是，开发编写单元测试，覆盖 99%的代码行。QA 做功能测试，优先覆盖开心路径，逐步补齐异常测试用例。这样兼顾开发效率和软件质量。

py 里，如果想发送 json 数据，正确的方法是：
```
r = requests .post(HOST, data=json_dump(json_data))
```
或者
```
r = requests .post(HOST, json=json_data)
```
既然你的 py 代码能正常工作，则表明服务端把你的 post 请求，以 formdata 格式处理

你的服务器接收的 post 请求，是 form data 格式的吧，不是 json 吧。
r = requests.post(HOST, data=json_data)

包的名字要用完整的路径，即包含你的 repo 地址

例如：gitta.local/library, gitta.local/account-srv

@hantsy 既然讨论技术，就说说你的解决方案？扣帽子的速度还是挺快的。

我不反对 RESTful，毕竟我也有在公司内部推行 RESTful，我只是反对迷信 RESTful，以为有了 RESTful，前景就是光明的，或者说只有 RESTful 才能解决问题。追求规范，却忘了为什么需要规范。

#159 我所说的问题，能请教一下你么？怎么才叫好呢？毕竟这个也是我在推行 RESTful 所遇到的无零两可的问题。

即使有公司所有接口用 POST，但只要他的文档写得好，容易检索，我就说它是好的 API。

我从来不轻易说某样技术 low，或者某样技术烂，我列举 Proto，是因为 Proto 里面只留下方法名和 Message，和其他 AML 不同，不需要再去纠结 http method 和 url。

你说你看不到你想要的，只不过是我们讨论的不是一个维度上而已。

@hantsy
如果只用 GET 和 POST 就已经能表达清楚，为什么一定要用 PUT 和 DELETE 呢？
“是能用 PUT，DELETE 表达的地方为什么不用呢？”，就那么想找个地方，把 REST 圣经实行下去么？

既然你认可，规范是用来降低沟通成本的。那么请看最近半年，每个月都跑出来一个“如何定义 RESTful”接口的月经贴，每次都没有结论，你觉得这本圣经还能降低沟通成本么？

Proto 定义接口： https://github.com/googleapis/googleapis/tree/master/google/api

@hantsy 什么叫做烂？什么叫做好？评价标准是什么？
只用 POST/GET 就叫做烂了？用 POST/GET/PUT/DELETE 就叫做好了？
只要遵循 REST 就叫做好了？那么怎样才遵循 REST 呢？能用上 PUT 和 DELETE 就叫遵循了？
LZ 例子：“获取对应学期下评语:[get] /back/remark/{termId} 删除数据:[delete] /back/record/{recordId}”
这叫遵循 REST 了？资源描述清晰么？ URL 设计合理么？

脱离实际问题，一直在自己有限的认知领域里纠结，转圈圈，正如楼上有人说的：“非要把 restful 当成圣经一样是不是傻？搞得自己弄个 restful 就高人一等一样。”

REST 还要求面向资源设计 path
究竟是：
/brand/{brand_id}/reseller/{seller_id}/car/{car_id}
还是：
/reseller/{seller_id}/brand/{brand_id}/car/{car_id}
还是：
/car/{brand_id}/{seller_id}/{car_id}
更好呢？
如果我要取消一个订单，究竟有 PUT，还是 PATCH，还是 POST，还是 DELETE 呢？
哪个才是好，哪个才是烂呢？如果这个是公开 API，那么请问业界用哪个作为标准呢？

规范，是用来降低沟通理解成本的。抱紧 REST 圣经，忘了本来的目的。
我对好的公开 API 的定义是，我只要看懂其中一两个 API，其他 API 我都基本能看懂了。

PS：proto 定义接口了解下，REST 不是唯一的出路。

@unco020511 人贵有自知之明，自己看看自己发的贴，同事已经告诉你不能用 put 和 delete，并告诉你原因，这是他们的规范。而你的问题呢？
你不是问，这样做主要出于什么考虑呢？而是问，我应该如何说服我的同事？
背后潜台词不就是：我的同事竟然称之为规范，哈哈哈哈，笑死人了，这年头竟然还有不知道 RESTful 才是规范的人，v2er 各位评评理，我该如何怼回去。（当然这里我用了夸张修饰啦）

哎，又是月经贴。
RESTful 本身不能算规范，更像是方法论，它告诉我们一种“说得通”的如何设计 API 的方法。并不表示它就是规范，全互联网只能按照它这一套来设计 API。
RESTful 的目的，是让 http method，url 具有了语义，简言而之，就是你看了我写的 method 和 url 上的单词，你就知道我的 API 是用来干嘛的了，不需要我额外的文档描述。这是它的最最最主要目的。
而网络传输，路由策略，网络安全等等，均不在 RESTful 所讨论的范畴里。

在你吐槽别人没有遵循 RESTful 那一套时，能不能先了解一下别人如此设计 API 的目的是什么？基于立场去讨论问题，是没有意义的，你连对方的立场都不许了解，上来就喷。

再来说规范，规范是一起共事的人达成的一种共识，价值在于降低沟通成本。如果你的团队已经有一套已经达成共识，大家已经熟知的约定时，你不应该去打破它，而是尽快掌握这套约定，成为团队的一员。如果你继续坚持你所认为的规范，让团队所有人都迁就你，那就已经失去规范本来的意义。

@classyk 所以 A 不在数据库中？所以 A 就要插入？
那说有 ABCE 四条记录又是什么意思？ ABCE 不在数据库里面？
不对啊，你刚刚才说 BC 在数据库里面的。所以 ABCE 四条数据，只有 BC 在数据库里面？

#12 为什么只有 AD 两条数据要插入数据库，而 BC 不用？
哦？貌似是有序的？我只能想到能够转化为这样的问题，两条字符串（ ABCE 与 AABCD ），求最长子串匹配，最后再求差异？

或者 LZ 先组织好语言再上来问？

搞反了吧？

拿别人的系统，对着重新设一遍