今天介绍一个在ai时代非常重要的实践 现在因为有了ai,代码变得非常便宜,一个模块写完的时间可能只有几十分钟,代码写好了,可能也会写单测,看着通过率100%很美好,但是最后发现,他测试的根本不是你想测试的东西 什么是TDD 在说这次分享最重要的东西前,先简单介绍一下tdd,tdd的中文名字是 测试驱动开发 ,意思是用一个非常简单的循环来测试一个很小的模块或者流程 这里介绍一下设计到的名词: 红测:必定失败的测试用例,在开发某个需求前维护 绿测:在需求写完后进行测试,如果成功了代表通过 TDD 真正的产物不是测试本身,而是你写出测试所体现出来的 设计 意义: 首先如果你能为一段逻辑写出简洁的测试时,说明它的边界是清晰的、职责是单一的。如果写不出来可能就是你设计的不行 红测的必要性 经过刚刚的抛砖引玉,现在开始进入正题 在旧时代(指的是ai发展以前),这个东西用的比较少,是因为单测很多时候写的太慢了,而且很繁琐,需要专人去写,非常麻烦,但是现在ai发展了写的非常快,但是也带来了一些问题 为什么需要红测 1, ai代码带来的不可靠性 人写代码的时候,速度本身不快,并且自己本来就会有审查的机会,但是agent不会,一小时几千行都是洒洒水,如果agent写出来自认为对的代码,就会带来很多的线上问题 2, "假绿"的结果,我说对就是对的 我认为这里是这篇分享最最最核心的地方,什么意思呢,你让ai写一个单测,他是基于代码写出来的,他是一个揣着结果来为了结果构造出来的结果,就像是一场比赛,如果他又当运动员又当裁判,那就没救了,写出来的单测都不好意思叫单测了 Agent 无法靠自己验证"我们是不是在做对的东西,它只能验证代码是否符合用例 我们应该怎么做 1, 在正确的时期写正确的东西 在计划期写用例,写一些 必定失败 的用例,这就是红测,代表你在实现需求前,一定是不满足的,可以显著避免agent沉迷在自我的幻想里面 我们要把bug或者是需求,当成检查.如果一开始写的红测居然绿了,那么有问题的就不是agent而是使用者了,你现在就应该停下写代码,来好好看看是不是哪里错了 2, 用前后的结果架起前后的联系 当需求/bug写完了之后,重新跑同一个单测,发现由红转绿,就说明你改的东西是生效的,是影响单测的根本原因,如果还是红的,说明你的代码实现的有问题 这里最重要的是,绿测只代表了结果态,而红测代表了起始态,如果结合到了一起才代表了你的需求/缺陷的状态流转 为什么要写单测 这里分享一些题外话,没有必要去一味的追求单测什么的,单测的用处很多就是要报错的,你现在写的单测代表了现在的agent的思考,未来报错了,就说明老的agent和新的agent产生了思考的碰撞,单测也是一个长期的设计,也许有一些实现的问题有一些问题,比如 选择错jdk了,然后当成红测 什么时候应该用单测,什么时候应该连数据库做自动化测试 前后端,可能因为前端的问题导致接口报错 等问题,这些问题,本文暂不讲如何解决,仅针对思考. 总体而言,tdd在ai时代是一个利大于弊的设计,期待给各位佬友带来启发 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/20 11:15:46