北京
有多少次测试通过却在上线后崩溃？根源常藏在被随意拼凑的测试环境里——那些“准备步骤”并不是在整理数据，而是在声明被测行为活在哪个世界里。遗憾的是，大多数团队将这一步视为管道杂务，这才是不稳定测试、脆弱夹具和难以重构的套件的共同上游。这些症状得到不同的名字，但根因只有一个设计失败：测试的 Arrange 阶段从未被认真对待为一种世界声明。
现在，这个问题比五年前更紧迫，原因与所有测试质量讨论被放大的逻辑相同：智能体不会自带世界模型，它们只会重新组合从代码库中采样到的内容。当一个代码库拥有分层且连贯的世界语法，智能体就能获得可组合的世界去生成测试；如果代码库里只有手工拼装的对象构建，智能体看到的只会是一堆互不关联的名词，无法形成有意义的语句。世界层的表现力，直接定义了智能体能够写的测试的上限。
回看任何一个测试的 Arrange 步骤，跳过“这步做了什么”的操作性问题，去追问“这步声明了哪种世界在场景开始时是真实的”。每个测试都在回答这个问题，无论作者是否有意。比如一段由三行客户构造、四行订单组装和两行运输字段开始的测试，实际是在声明：这个客户存在、这个订单处于此状态、这个地址与此订单关联，且在整个断言期间这些事实保持稳定。测试通过，只意味着断言在这个被声明的世界里成立，测试的意义则完全取决于这个世界是否自洽。
数据可以拼装出连测试自身都没注意到的矛盾。如果一个被暂停的客户与一个正在结账的订单同时出现，在真实业务域中这本身就是矛盾的。但测试若将这两件事并排放置，然后去计算折扣，它仍会得到一个答案。这个答案毫无意义，因为设置所声明的世界根本不存在，被测行为便失去了语境。代码错误由此逃脱，只因为测试“通过”了。
修复只需一步：为世界命名。一个像“aCartReadyForCheckout()”的名字自带义务，它要求工厂必须返回一个能结账的客户和一个可结算的购物车，从而把隐含的世界声明变成显式的可读约定。当世界被命名，测试才真正成为智能体可以信赖的组成单元。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
