没恶意，只是 Monaco 的功能还是比较丰富的，可能不是所有场景都能把它替换掉。

虽然问 gpt 还挺有意思的，但是换了个工具也叫优化嘛

比如订单号，首先你这个订单号要在数据库里面存在，然后我可能通过这个订单号查询到商品信息，然后我还要对商品信息做校验，不同的商品信息有不同的逻辑，那我是需要先要造商品，再造订单，再用造出来的订单号作为造数工厂的数据吗？拿感觉和我自己写个前置接口的方式也没区别吧。

请问这个造数工厂之所以实现逻辑能打通，是不是基于【现在很多微服务基于 DDD，后端开发各自专注于自己的领域中，对依赖服务的内部逻辑和数据结果并不关注，只关注交互接口提供的数据结构和含义。】这句话的呢？如果对数据有校验的场景造数工厂就无法使用了。

也不是不行，你要先解决一个问题，在页面还没开发之前，你人是怎么思考的，你准备如何着手 UI 测试，这里说的不是自动化，仅是 UI 测试。如果你本身都不知道怎么做，何谈自动化。
如果是做准备的话可以根据 UX 和需求文档把大致逻辑捋顺，mock 一些 xpth，后续再对接上真实的。

异步的呗，获取的时候还没被渲染上 dom

哪个岗位不卷，都卷，只是换个方式卷，一样累。

完全不够

这回答也太 GPT 了。。。。

我是这么觉得的，只写亮点的工作当然是非常好的，但是需要满足一些前提。
1、确定这些亮点是对方公司所需要的
2、对于自己的职业有非常明确且坚定的规划，除了亮点工作外都不做。
我觉得做到这两点是非常需要勇气的，或者说不是所有的测试人员都有实力能够做到。大部分的测试人员还是希望能告诉公司方自己涉猎的广度，在广度中找到匹配公司需求的能力，从而入职。
如果说您只做侧开，或者只做侧开中的某一项具体实现，并且非常精通，那么我佩服你。但是你也需要承担分公司对你技能应用不匹配的风险了。