matrix1010

设置密码是免费功能。但是首先你的 ES 是暴露在公网的？

早上醒来突然想到: 在国内这个开发几乎不写测试的环境下，做个低代码 /无代码测试平台可能挺有钱途。欢迎有钱有人脉的老哥联系我🧐

@l00t 重要的其实是有测试，单不单元是很灵活的。

再摘录一段大佬的话: I will usually use mocks for that (I'm not a big fan of mocks, and prefer to avoid them wherever possible, but I think mocking network-comm responses is reasonable). Though "it depends": sometimes I do launch the software, but from within a test.

@sulfoh6 "写单元测试过程中可以顺手解决掉几个低级错误。但基本上就到此为止了" 首先，程序员是很容易犯低级错误的，就算是老司机也经常因为低级错误翻车。如果你的低级错误直到 QA 阶段才被发现是很严重的内耗，也会降低团队间的互相信任。
"很多设计上的问题、接口的问题、性能问题、安全问题、并发问题...，单元测试都无能为力" 真的无能为力吗, 还是只是你们团队的技术水平不太够，或是你只是为了糊弄一下随便写个测试？
"因为伴随着单元测试的还有敏捷开发的其它要素，势必让依赖内部基础库的其它产品团队充当小白鼠" 敏捷开发配合自动化测试配合严格的 Code Review ，再加上技术实力靠谱的团队，这样才能实现真正的高质量快速迭代，你可以专注于迭代新功能，而不是担心别人加了个功能 /改个功能把你原来能用的东西改坏了。当然，有测试的话甩锅也比较方便。
"我呆过的一个 MNC 公司里很多印度团队，他们搞 pipeline 的漂亮花哨程度可以把上层哄得不要不要的" 也别总是黑印度工程师，国内很多工程师可能并不如印度工程师。另外国内大厂很多是依靠很大的 QA 团队进行人肉测试，才确保了你用到的东西没问题。

卷卷

其实我觉得所有代码都应该有测试，只是重要度低些的代码测一下功能正常就行，而重要度高的代码则要把各种情况都测一遍

实际上没多少公司是 TDD 的，但不代表不需要单元测试。看看大佬怎么说 https://twitter.com/mitchellh/status/1458478408749309960?s=21

@partystart 不太清楚你的实际情况，但如果让我写一个类似的接口差不多是这样。先用 ORM 查出数据与关联数据，shop = shop.query().where(id=1).withItems(func(q) {q.withextra()}).all(), 然后直接把这个 struct 转成 json

你这看上去像是 ORM ，那可能是你的 ORM 不太行. 另外如果真的很多地方用并且模式差不多可以考虑写代码生成。This is the way