基于Cucumber/Gherkin实现应用代码生成的可行性探讨

能不能借助功能文件生成应用代码？ #

能，但这完全偏离了Cucumber、Gherkin这类BDD工具的设计初衷。你可以自定义步骤定义的逻辑，让它不再执行测试断言，而是输出应用代码片段（比如写入本地文件、拼接代码字符串）。举个简单例子：

Gherkin功能文件步骤：
当用户创建一个名为"测试订单"的订单

对应的步骤定义（Java示例）可以改成：

@When("当用户创建一个名为{string}的订单")
public void generateOrderCode(String orderName) {
    String code = "public class Order {\n" +
                  "    private String name = \"" + orderName + "\";\n" +
                  "    // 订单核心逻辑\n" +
                  "}";
    // 将生成的代码写入本地文件
    writeToFile("Order.java", code);
}

但这种做法本质上只是借了Gherkin的语法壳，和BDD测试的核心价值毫无关系。

这是不是不良实践？是，原因如下： #

• 工具定位完全错配：Cucumber的核心是用自然语言打通业务人员和技术人员的沟通，最终落地到测试验证。用它做代码生成，等于把一个测试工具硬改成代码生成器，既没有专业代码生成工具的配套能力（比如架构约束、代码格式化、依赖管理），也浪费了BDD工具的核心价值。
• 维护成本爆炸：自然语言描述的需求天生存在歧义，用来生成代码会把歧义直接带到代码里。后续需求变更时，你既要修改功能文件，还要同步调整步骤定义里的代码生成逻辑，稍有不慎就会出现生成代码和需求不匹配的情况，维护起来比直接写代码麻烦得多。
• 丢掉BDD的核心意义：BDD的逻辑是“先明确业务行为，再实现代码，最后用测试验证行为是否符合预期”。如果反过来用功能文件生成代码，等于跳过了架构设计、逻辑思考的环节，生成的代码只是满足字面需求，很难符合项目的架构规范，同时也失去了测试验证的环节——你没法确认生成的代码是否真的能实现预期行为。
• 代码质量无法保障：复杂业务逻辑（比如分支判断、异常处理、幂等性设计）靠自然语言根本没法精准描述，生成的代码往往是粗糙的骨架，需要大量手动修改才能用，反而降低开发效率。而且自动生成的代码通常冗余、缺乏优化，长期积累会导致代码库混乱。

内容的提问来源于stack exchange，提问作者user2430147