AI时代最速消亡技术之BDD

多客科技

作者：微信文章
受市场低迷和AI编程冲击的双重影响，吃编程这碗饭的程序员，未来几年中会发现自身的稀缺性在消失，手里的饭碗越来越脆，越来越少了。AI编程取代大多数程序员的工作是必然趋势，身处AI大潮，既然走在被取代的末路上，倒不如闲看哪些技术先死掉，提前避坑。


AI编程技术一日千里，AI应用框架还没来得及成熟就已经开始残酷汰换了论AI时代最速消亡的编程技术，个人会先给BDD投上一票。
BDD 的全称是 Behavior-Driven Development（行为驱动开发），它是一种敏捷软件开发方法论，核心是通过 “软件行为” 作为沟通桥梁，打通业务人员、开发人员、测试人员之间的认知差异，确保开发出的产品符合业务预期。

BDD 源于 TDD（测试驱动开发），但更强调 “以业务价值为导向”，而非单纯以 “测试用例” 为导向。它的核心思路是：

在写代码前，先由业务、开发、测试三方共同定义 “软件应该具备的行为”（比如 “用户登录成功”“订单支付失败时提示错误”），并用自然语言 + 结构化语法（如 Gherkin 语言）描述这些行为场景，再基于这些场景编写可执行的测试用例，最终驱动开发实现对应的功能。

BDD所谓的自然语言描述“业务行为（behavior）”，是需要经由转换器翻译成“可执行的测试流程(test ops)”，从而再驱动开发实现业务需求（Drive Dev)。

在我看来就是一个脱裤子放屁的伪命题，徒增实体，收益有限。

因为BDD开发最难的地方，是如何长期维护一个自然语言转测试代码的方言体系，所谓"NL2TestOps"。
这玩意儿非常考验思维到语言的设计，然而大多数程序员DSL都设计不好，想在BDD这个套路里做到自然语言转译测试代码，语法准确，语义完备基本是不可能做到的。



某BDD领域巨佬的履历，显示BDD被AI推理取代的时间线

下面我会用实际例子说明为什么有这样的判断。

比如，我们现在有一个业务需求：
小狗阿黄吃掉了小鸡，吃不掉小猪。
经过BDD翻译，最终得到的测试流程可能是这样：
yellow = Dog()assert yellow.eat(Chick()) is Trueassert yellow.eat(Piggy()) is False

为了实现上述效果，我们有两种方案去实现，使用编译器，或者使用BDD框架。

按照编译器的做法，你要经过下面这几个步骤才能从自然语言转换成程序可理解的内容
1. 分词  // 大多数BDD框架这里就卡住了，因为你必须给出精确的（或者正则可匹配的）自然语言关键字2. 符号化3. 语法分析4. 语义分析5. 执行计划生成 // 到这里已经可以翻译成测试流程代码了。

还是这个例子，具体一点的编译过程可能是这样：

原文：
小狗阿黄吃掉了小鸡，吃不掉小猪。
分词：
小狗, 阿黄, 吃掉, (了）, 小鸡, 吃不掉, 小猪
基于关键词字典的符号化：
$KW_CLS_小狗$,  $OBJ_阿黄$, $KW_OP_吃$, $CLS_小鸡$, $KW_NOT$, $KW_OP_吃$, $CLS_小猪$
语法分析：
<分析上面的符号流是否满足预设的语法树(语法轨道图)定义>
语义分析:
...
执行计划生成：
<生成可执行测试流程代码>
从自然语言到可执行测试代码之间这一通操作猛如虎，说破天去，也就是为了能让“用户”使用自然语言描述测试过程，

但是BDD毕竟是一个草台班子概念，工程实践上远没编译器那么复杂。

BDD 经典框架gherkin的工程方式，其实是“完形填空”，使用自然语言“固定表达”的方式简化处理.

比如上述例子中的，小猪、小鸡、小狗 就是可以定义为类关键字，

你想表达小狗的实例，就必须用“小狗” 阿黄， 这样的方式表达阿黄是一个小狗类的实例。



可见BDD的工程实现核心并没有多复杂的理论。

但是BDD有一个特别拧巴的地方，它所谓行为驱动的初衷，是为了降低测试用例的编写、维护门槛，理念很美好。但在工程实践上，又需要测试开发者发明一套定制化的技术方言体系，让不会写代码的用户去学这套技术方言

对使用BDD体系的用户来说，心智上的成本是增加的，而不是减少，这就违背降低测试成本的初心了。

写一个用例，还要先了解自然语言在BDD方言体系里会怎么转换，用户嫌麻烦，不高兴。

如果用户强势，说”老子的需求就这么写，怎么转换成测试你自己想办法。”

那么维护BDD方言转译parser的这些测开，就死翘翘了，终究逃不过天天在BDD parser里补锅。BDD工程会随着用例的膨胀而变得难以维护，越来越慢。



即便BDD的“自然语言测试用例”做出来了交付团队，最终用户也只是那少数的“不会写代码的”PD或者售前，受众也相当狭窄。

这就导致BDD的实际效果大打折扣，很容易变成测试开发自嗨的玩具，因为BDD用例本身就缺少可扩展性，用例堆积起来之后持续维护成本巨高。

维护了半天，BDD驱动既没有稳定性，也缺少流行度，只能自己玩死自己

还不如一开始就设计个DSL，面向半开发者，使用者多少得懂点DSL规则约束。

DSL的开发，则需要定义清楚语法规则，同时写好parser和executor（巨坑醒目：一定要版本化控制）

这样从测试用户到执行侧，高低还有一套框架代码维护着，腐坏速度能控制得住。
到了AI编程时代，DSL方案因为其结构化表达的特点，也更容易被AI agent所理解，DSL的语法规则也可以换成system prompt，剩下的解析、执行工作，全部交给agent处理，说不定AI理解的比你还到位，能在精确与模糊之间取得令人放心的平衡。
按你胃，在整个程序员群体都可能被AI取代的今天，作为测试领域TDD细分赛道下的传统BDD，已经完全失去了存在的价值。AI agent对自然语言的理解能力远超正则匹配；工具调用，代码生成也只在一瞬间。有AI加持，生成代码已经不是门槛很高的事情了。而TDD这个思路在AI coding的时代依旧有效，让AI生成测试用例，从而圈定AI coding的实现范围，对约束AI生成代码有很好的效果，如果硬拗概念的话，这或许也可以称之为一种AI时代的BDD。
关于TDD在AI coding方面的使用经验，值得单开一个话题，我们回头再聊。