CI/CD 可以说是这些年发展最快的方向之一。以前 jenkins 什么的部署、设置啥的还有点儿小麻烦，现在几大 repo 服务商 github 等都自带 docker + yaml 的解决方案，可以设成 build 跑通了才能 merge PR。aws 也有 codebuild/pipeline/deploy 等类似的解决方案或者接口。

现在不少开源项目都实现了完全自动 CI/CD，之前给 DefinitelyTyped 提过一次代码，整个过程有个 bot 辅佐。只要测试全过，至少一个 member 已经 review 了，merge 的主动权可以在提 PR 的人手中，之后大概几分钟就能发布到 npm。前脚 merge 了，后脚直接就给公司的项目提了个 PR 移除自己的类型声明补丁。整个过程在我开源项目 issue/PR 中是体验最好的一次，不像很多项目半年都没人理，等收到 review 邮件，我都不记得有提过代码这回事了。而且 merge 的主动权还给提 PR 的人一些成就感，反正我是很乐意下次发现问题再提代码的。

测试也是分很多层，gui 的项目至少也是能做 unittest 的。当然还是取决于项目的设计，我们公司最复杂的 rails 项目是从90年代 oracle db 起家的，核心逻辑都在数据库里。导致的结果就是，unittest 没多大意义，因为 ruby 这边业务逻辑不完整。而 db 这边所有人都不知道该怎么搞 unittest。不重构的话，目前最好的解决方案就是 e2e test，不过这方面 web 还是工具非常多的，直接在 container 里面跑 headless 浏览器。

理想化的设计，还是尽可能解耦 UI 和业务逻辑，把界面操作转换成 action + params 的设计。毕竟就算是能做 e2e test，速度跟 unittest 也是没法比的。就算是需要人工测，把测试量降到最低也算是部分达到了目的。

关于 e2e test，我们对老项目的思路是这样的，首先是要有 happy path 作为基准。开发新功能至少不能有明显的问题，直接干掉 baseline。之后每发现一个新 bug，就把它做成一个 test case，确保不会发生第二次。至于老的 bug，基本上是不可能有时间写测试的，再发生就当新的写测试。

想法很美好，但现实还是非常残酷的。我们的项目老到一直都是 export/import db，然后删数据，因为很多年没有人做过从空 db 建出一个能跑的项目来了。最关键的还是人的问题，我们的 rails 是一个 monolithic app，不管能不能该不该的功能都一股脑塞进去。导致的结果就是，一个完全不重要的模块没配置好，也会导致整个 app 跑不起来。但是做这些决策的人既不会用 docker，又不理解 decouple 的意义，还在继续往里面塞垃圾……

我们最惨的就是 db，因为是各种复制出来的，哪里多了少了个 column/constraint 是完全不知道的，直到客户发现问题了才能人肉发现。SQL 代码直到进了 QA 环境，所有依赖它的都编译不过了，很多功能用不了，然后人肉去查哪个出的问题。我花了很多时间精力，终于在引入 liquibase 后，把结构（tables/constraints/indexes/foreign keys）从 SQL 变成了 xml，然后 objects（views/mviews/triggers/procedures/functions/packages）按照依赖关系顺序执行，这样终于能在 build 里解决 SQL 编译不过这种低级问题了。而且利用 xml 去验证生产数据库的结构，也是很容易实现的。但我们这哥们儿对 liquibase 不是用 ruby 写的超级有意见，目前又在子项目里变着法子写 rails 的 DSL。我问他一个很实际的问题，怎么 drop constraint，他说没试过不知道。我估计要是问，怎么去验证数据库结构的话，他又得山寨一堆 regexpr 出来。跟他说无数次，不管是 SQL 还是 DSL 都是数据跟逻辑 coupled，很难直接用数据；XML 只有数据，想生成啥都没问题，就是不听。总之不管能不能满足我们的需求，只要是 ruby 就是好的，SQL 也是好的（因为数据库只能用它），其它都是坏的。我们的一堆应用初始化的数据也是，各不相同的 ruby 代码，完全是可以写成 CSV 之类的文件，然后用写代码导入，还能写测试。现在就是直到生产环境里某个参数被意外改了，才发现导入的代码有逻辑问题，还没法写测试。

e2e test 也是，我主张用 playwright 写，这样任何人都可以跑。我们 support 团队把功能做成视频，相当于文档，给客户用。因为 node 环境很容易在 windows 上面装，理论上可以他们本机跑，直接出视频或者本地录屏，然后就可以直接拿去剪。而且 support 里面有几个人懂 sql，也很愿意学东西。加上目前 chromium 有把操作录成 json 的功能，给出些示例，做个培训教他们自己写也不是不可能。我们还能拿过来直接当 happy path 用。他偏要用 ruby，因为自己不用学新东西。我就不理解了，为啥天天写 js，反倒需要学新东西了。测试数据也是，有一个写 java 的、CI/CD 经验丰富的跟我们推 factory pattern。后来我演示了自己的思路，把测试数据写成数据文件（yaml 或者 json），然后利用 orm 直接导入，他马上就意识到我 decouple 数据和逻辑还能完成许多其它事。我们这哥们儿只用过 ruby，之前有个做测试的公司给我们做推广，他们用 java 自然讲了些 patterns 在测试里怎么用。我们这哥们儿好像发现了新大陆，如获至宝，然后开始各种俄罗斯套娃，测试也非要用 factory_bot。结果现在 sales 团队自己雇了个实习生，做数据导出和导入的工作。基本上就是本来 dev team 能做，或者应该主导的工作，都被别的团队给干了。不但捞不着名，人家做出来的好处你也用不上。我们老板不懂技术，我也不知道他会不会怀疑我们团队的能力……不过我们开发任务重，倒也算是有借口。

因为一堆东西敲不定，我给出解决方案甚至 poc 都出来了，人家不同意，又给不出自己的方案，所以现在只能雇外面的人来搞。看过 demo 人家自己基于 java 开发的 BDD 架功能非常强大，我很多只有初步想法的东西，人家都已经有完整的实现了。结果老板又觉得太贵，好像说先用一个月看看，估计也不会有下文了。不过听说已经发现好多 bug 了。顺便一提，人家的框架主要是自己写的 java，然后说也可以写 python。我觉得人家说的挺明白的，虽然 bdd 的形式，但核心代码是十来年的积累，那 py 八成是张皮调用一下呗。我们这哥们儿一听，不行，我们 ruby 有 cucumber，拿过来应该可以直接用的，你们写 ruby。于是对方很委婉的表达，开源库没有他们的独家功能，我们这位非得说 ruby 也行……

反正我现在的感觉就是，人的思路和想法改变不了，再好技术也没用。只要有意愿、有资源，而且思路开阔，一切都不是问题。

【 在 xunery (寻) 的大作中提到: 】
: 看很多老外的项目管理书籍，自动化测试是很重要的一环，国内实施的公司多吗?
: 尤其是有gui的应用程序，我都想不到方法怎么搞自动化
: web api可能相对容易点
: ...................
--
修改:eGust FROM 203.211.108.*
FROM 203.211.108.*