- 主题:大家公司的代码都做自动化测试吗
踹了这位用ruby的
【 在 eGust 的大作中提到: 】
: CI/CD 可以说是这些年发展最快的方向之一。以前 jenkins 什么的部署、设置啥的还有点儿小麻烦，现在几大 repo 服务商 github 等都自带 docker + yaml 的解决方案，可以设成 build 跑通了才能 merge PR。
: ....................
--
FROM 124.160.154.*
那是不可能的，人家职位是 architect，而且是这个 rails app 的元老级人物。我估计假如跟总经理闹矛盾到必须走一个的程度，老板估计也只能让总经理走人了。
【 在 KEILLY (米饭) 的大作中提到: 】
: 踹了这位用ruby的
--
FROM 203.211.108.*
感谢这么大篇幅的回复
但是不同类型的软件可能测试方法天差地别。对于一个小团队来说，如果想实施自动化测试的话是不是只能依赖现成的测试框架，就是想问问大家有什么好的方法或测试框架。
每个模块暴露的接口都要写各种测试case吗？那些不向外暴露接口的模块怎么处理？比方说exe程序。
只能自己写针对性的代码？这样的测试代码量可能很大吧，亦或者有类似liquibase针对数据库的测试框架
现在团队做的产品涉及web前后端（go，js，vue），Windows客户端（gui，Windows service）各种类型应用
【 在 eGust 的大作中提到: 】
: 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 浏览器。
: ...................
--
FROM 124.126.202.*
谢谢，回头研究一下
【 在 xiaoju 的大作中提到: 】
: 所有的GUI系统都有支持automation的api，直接拿来用就行，和web一样
:
--
FROM 124.126.202.*
我前公司用的是MFC开发的gui，是的你没看错，用的是MFC，但仍然有自动化测试，公司自己开发了一个测试框架，用Python通过框架去调用Windows的API，点击界面上的菜单按钮什么的，还能读到弹出来的对话框的文字来自动检查。我们写的新代码必须全部被自动化测试覆盖，不然不能提交。
--
FROM 120.21.222.*
哈哈。有开发这测试框架的精力，都不如把原来的程序改成 Qt 写，直接用 Qt 现成的自动化测试好了。
【 在 dpblue (deep blue) 的大作中提到: 】
: 我前公司用的是MFC开发的gui，是的你没看错，用的是MFC，但仍然有自动化测试，公司自己开发了一个测试框架，用Python通过框架去调用Windows的API，点击界面上的菜单按钮什么的，还能读到弹出来的对话框的文字来自动检查。我们写的新代码必须全部被自动化测试覆盖，不然
--
FROM 110.81.14.*
干货啊
顶
【 在 eGust (十年) 的大作中提到: 】
: CI/CD 可以说是这些年发展最快的方向之一。以前 jenkins 什么的部署、设置啥的还有点儿小麻烦，现在几大 repo 服务商 github 等都自带 docker + yaml 的解决方案，可以设成 build 跑通了才能 merge PR。aws 也有 codebuild/pipeline/deploy 等类似的解决方案或者接口。
: 现在不少开源项目都实现了完全自动 CI/CD，之前给 DefinitelyTyped 提过一次代码，整个过程有个 bot 辅佐。只要测试全过，至少一个 member 已经 review 了，merge 的主动权可以在提 PR 的人手中，之后大概几分钟就能发布到 npm。前脚 merge 了，后脚直接就给公司的项目
: 测试也是分很多层，gui 的项目至少也是能做 unittest 的。当然还是取决于项目的设计，我们公司最复杂的 rails 项目是从90年代 oracle db 起家的，核心逻辑都在数据库里。导致的结果就是，unittest 没多大意义，因为 ruby 这边业务逻辑不完整。而 db 这边所有人都不知道
: ...................
--
FROM 221.200.28.*
大的小的都一样啊，正常都是拿成熟的测试框架直接用啊。
unittest 是非常成熟的，稍微新点儿的语言都直接自带了，老点儿的也都有主流的包。比如你说的 go 就不算老，直接就能 go test。像 python、ruby 这类脚本语言就算老，加个测试也就一个官方包而已。js 的话，jest 是占主导地位的，还有 mocha 也比较流行。
理论也很简单，就是保证每个单元都能单独正常工作，出 bug 就在相关测试里加 case。设计上就是分层，尽量相对独立，可以单独测试。不同层之间 interface 尽量稳定，必要时按照接口 mock 其它层，这样尽量保证每一层的功能稳定。很多静态语言的框架里，有时甚至专门套一层，就是为了方便 mocking，然后就搞成了俄罗斯套娃。
测试有一些主流的标准，然后以单独的包形式提供扩展功能。比如想用 jenkins，一般是加个 junit report，然后设置去哪找测试生成的 junit xml 文件就可以了。jest 只是一个基本测试框架，想用 bdd 的话就加个 jest-cucumber；同理再加个 jest-puppeteer 就可以用 bdd 的形式跑 e2e 的 puppeteer。e2e 的 web 测试框架非常多，也非常成熟，老一点儿的有 selenium/webdriverio 基本上啥语言都有封装，不那么老的比如 cypress 也挺流行，新一点的 puppeteer/playwright 能做的都不止测试了。我直接用 playwright 爬网页，而且它自己还有个跟 jest 接口类似的测试框架，还能直接 mock request。放以前不但得搞个 mock 用的 web service 模拟第三方 api（虽然其实也就几个静态 json 而已），还得改代码测试的时候指向自己的服务。
按照现在的主流 web ui 框架，比如 react、vue 之类，组件化的设计可以单独测试，比较流行的有 storybook。但是都对组件的组织形式有相当高的要求，不然需要 mock 的东西太多，就很难持续进行下去了。
而开发也有 tdd，先把测试写好，这样基本的工作单元和接口都已经设计好了。然后再按照测试写代码，自然跑通，而且 coverage 直接就100%。这也是为啥 pure function 最适合写 unittest，每个函数都可以单独测，跑通了就一劳永逸。
另外，liquibase 不是测试用的，而是专门做 db migration 的工具。我们之前 rails 里写的 migration 只管跑 sql，之后什么状态完全不管。liquibase 对于一般的东西会做个状态认证，比如 foreign key 加不成就挂掉，而 stored procedure 也是手动加了一行代码（当然是自动生成的）看一下状态，不正常就直接挂掉。
【 在 xunery (寻) 的大作中提到: 】
: 感谢这么大篇幅的回复
: 但是不同类型的软件可能测试方法天差地别。对于一个小团队来说，如果想实施自动化测试的话是不是只能依赖现成的测试框架，就是想问问大家有什么好的方法或测试框架。
: 每个模块暴露的接口都要写各种测试case吗？那些不向外暴露接口的模块怎么处理？比方说exe程序。
: ...................
--
FROM 203.211.108.*
说实话这是正经做产品的。很多非技术出身的老板都搞不明白，虽然短期搞测试是增加成本的，但长期来看绝对更省钱。
我们公司目前大概也就6个人主要写代码（不算 plsql），俩 QA 纯人工搞测试，说是打算明年再招个10人。目前基本上平均每个月，我会有一个礼拜时间专门处理 prod/uat 环境发现的 bug，或者回答其他团队的问题，为啥这俩东西输入的数值一样，结果却不同。我感觉就我们现在这水平，到时候破坏力就超过建设速度了。换句话说，bug/feature 的产出比会超过1，到时候我除了给人擦屁股就不用干别的了（当然我自己屁股也不干净）。
【 在 dpblue (deep blue) 的大作中提到: 】
: 我前公司用的是MFC开发的gui，是的你没看错，用的是MFC，但仍然有自动化测试，公司自己开发了一个测试框架，用Python通过框架去调用Windows的API，点击界面上的菜单按钮什么的，还能读到弹出来的对话框的文字来自动检查。我们写的新代码必须全部被自动化测试覆盖，不然
--
修改:eGust FROM 203.211.108.*
FROM 203.211.108.*
世界从来没那么简单
很多产品是用一次就扔，如何用最低薪员工在最短时间内做出来才是第一
有的产品是为了花钱，如何让甲方不可摆脱才是第一
【 在 eGust (十年) 的大作中提到: 】
: 说实话这是正经做产品的。很多非技术出身的老板都搞不明白，虽然短期搞测试是增加成本的，但长期来看绝对更省钱。
: 我们公司目前大概也就6个人主要写代码，说是打算明年再招个10人。目前基本上平均每个月，我会有一个礼拜时间专门处理 prod/uat 环境发现的 bug，或者回答其他团队的问题，为啥这俩东西输入的数值一样，结果却不同。我感觉就我们现在这水平，到时候破坏力就超过建设速度
--
FROM 27.91.71.*