怎么测试驱动ChatGPT编程

发布时间：2023-03-23 10:41:55 作者：iii
来源：亿速云阅读：135

这篇“怎么测试驱动ChatGPT编程”文章的知识点大部分人都不太理解，所以小编给大家总结了以下内容，内容详细，步骤清晰，具有一定的借鉴价值，希望大家阅读完这篇文章能有所收获，下面我们一起来看看这篇“怎么测试驱动ChatGPT编程”文章吧。

nodeJS用下面的yaml描绘的数据结构得到一个新的数组:

base:
  steps: 10
  batch_size: 1
  poly:
- template_prompt:
    template: >
        a cat,
        ${ chara }
        ${ facial_expressions }
    meta:
      - chara: #  这里改成了数组
        - Abyssinian,
        - cat_in_boots,
      facial_expressions:
        - (smile:1.5),  
        - (smile:1.2),  
        - smile, 
    steps: 20

可能的输出：

[
{
steps: 20,
prompt: 'a cat,\nAbyssinian,\n(smile:1.5),\n',
batch_size: 1
},
{
steps: 20,
prompt: 'a cat,\nAbyssinian,\n(smile:1.2),\n',
batch_size: 1
},
{
steps: 20,
prompt: 'a cat,\nAbyssinian,\nsmile,\n',
batch_size: 1
},
{
steps: 20,
prompt: 'a cat,\ncat_in_boots,\n(smile:1.5),\n',
batch_size: 1
},
{
steps: 20,
prompt: 'a cat,\ncat_in_boots,\n(smile:1.2),\n',
batch_size: 1
},
{
steps: 20,
prompt: 'a cat,\ncat_in_boots,\nsmile,\n',
batch_size: 1
},
]

要求：

假设上面的yaml转成json的转换代码我已经写完了

我需要遍历poly下的所有的顶层元素

遍历过程中，要处理template_prompt元素的子元素：

从template中读取作为模版。

读取meta中的属性，因为属性可能每次都不一样，是不确定的，所以不能硬编码。

然后基于meta中的属性，把template作为 string literal 解析，这个解析代码我已经有了，假设名为render_string_template，可以不实现，留一个函数接口即可。

要遍历组合meta中的每一个属性组形成一个数组，

每一个属性组可能只需要看做一个对象，当且仅当每一个属性值都为单值

每一个属性组可能也需要展开，当且仅当任何一个属性值有多值，比如 facial_expressions 有一个值，chara有两个值，那么应该生成1*2也就是两组属性放入这个数组中，这个数组和template会被传入render_string_template函数，最后会获得两个prompt字符串

将生成的个prompt字符串数组和template_prompt元素之外的其他元素合并成一个对象，要求在同一级别。prompt字符串数组有几个元素，就会合并成几个对象，并放入一个新数组中，我们称之为ploys。

继续遍历，直到遍历完所有顶层元素，所有元素都放入了polys中。polys是一个一维数组。

将ploys中的每一个元素与base中的属性合成一个新的对象，base的属性展开与prompt属性同级，当ploys中的每一个元素的属性名与base中的属性名相同时，覆盖base中的属性。这些新对象组合出的数组就是我要的数组

果然就得到了预期的结果。

这一个动作，让我打开了思路，用输入+输出框住它生成的边界还是挺好用的。输入+输出框住边界？这不就是测试吗？

停下来想一想

从我们的体验来看，确实啊，ChatGPT生成的是有点不稳定。《The End of Programming》说的没错，底层确实有点混乱与疯狂的味道，起码不太稳定。但这事也就听起来很吓人，说实在的，人就比ChatGPT稳定多少呢？我这个人比较粗心大意，我写代码的时候也经常脑子一抽，写出一些事后看自己都想抽自己的脑残错误，所以我自打听说了TDD，很快就变成了坚定地TDD原教旨主义者，没有TDD的世界对我们这种人来说本来就是混乱与疯狂的，要说驾驭软件开发过程中的混乱与疯狂，那你是问对人了。

那么回顾一下TDD是什么？下面是一个复杂版

怎么测试驱动ChatGPT编程

基本上就是，先写一个测试用例，然后执行，得到期望的失败，什么是期望的失败呢，比如说，你写了一个add函数，接受两个参数，然后你写了一个add(1,1)，你期望的失败可能是返回某个值，他不等于2，实际你执行的时候呢，报错，说add函数不存在，这就不是你期望的失败。你要调整环境到你期望的失败，然后开始写实现，写完实现再执行，如果测试不通过了，就接着改实现，直到通过。如果通过了，就问自己要不要重构，如果要重构，就改实现，改完的还要通过测试，如果不想重构了，那就写下一个测试用例。总之就是这么个往复循环的流程。

如果上面那个复杂版让你觉得很晕呢，可以看这个简单版：

怎么测试驱动ChatGPT编程

红表示测试执行失败，绿表示测试执行通过，重构就不用解释了。所以永远是绿了重构，重构完可能红可能绿，红了就让他变绿。只有变绿后，可以开始下一次循环。

上面这些图讲的是TDD的过程，我个人觉得更核心的是，在实现代码的这个过程中，你同时生产了一套自动化测试，他可以在你将来不管是加新功能还是修Bug还是重构，都不会陷入按下葫芦起来瓢的窘境。那么在ChatGPT的时代，这个方法还能用吗？总感觉哪里需要修改一下，不过没关系，我们先走起来，边走边想。

想好了，继续出发

那么既然是TDD，应该先写测试，但是我实现都写完了啊。算了，这也是大多数项目的现状，那就先补个测试吧。但是补测试是个很烦的事情啊，我灵机一动，要不……让ChatGPT给我搞？它能行吗？谁知道呢，试试又不花钱。于是我就说：

给下面代码设计一些测试用例：

module.exports = function render_my_yaml_dsl(data){
const vm = require('vm');
- // 定义一个函数用于渲染字符串模板
function render_string_template(originalScriptTemplate, intention) {
    // console.log(intention);
    // 省略渲染代码
    const execScriptTemplate = "`" + originalScriptTemplate + "`";
- const script = new vm.Script(execScriptTemplate);
    const execScript = script.runInNewContext(intention);
    // console.debug(execScript);
    return execScript;
}
- // 定义一个函数用于展开属性组合
function expand_attributes(attributes) {
    const result = [];
    attributes.forEach(obj => {
        Object.values(obj).forEach(val => {
            if (Array.isArray(val)) {
                val.forEach(v => {
                    result.push({ ...obj, [Object.keys(obj).find(key => obj[key] === val)]: v });
                });
            } else {
                result.push(obj);
            }
        });
    });
    return result;
}
- const polys = [];
- for (const poly of data.poly) {
    const { template_prompt, ...other } = poly;
    const { template, meta } = template_prompt;
- const variableGroups = expand_attributes(meta);
    const prompts = variableGroups.map(variables => render_string_template(template, variables));
- for (const prompt of prompts) {
        polys.push({ prompt, ...other });
    }
}
- const result = polys.map(poly => ({ ...data.base, ...poly }));
return result;
}

是的就是这么任性，代码直接扔给他。然后我得到了下面的回复:

以下是一些可能的测试用例：

当输入参数 data 为空对象时，函数是否能正常运行并返回一个空数组？
当输入参数 data.poly 为空数组时，函数是否能正常运行并返回一个空数组？
当输入参数 data.poly 不包含任何属性组合时，函数是否能正常运行并返回一个包含原始数据的数组？
当输入参数 data.poly 包含一个属性组合时，函数是否能正常运行并返回一个包含根据属性组合渲染的数据的数组？
当输入参数 data.poly 包含多个属性组合时，函数是否能正常运行并返回一个包含根据所有属性组合渲染的数据的数组？
当模板中的字符串模板包含模板变量时，函数是否能正常运行并渲染模板变量？
当模板中的字符串模板包含 JavaScript 代码时，函数是否能正常运行并执行 JavaScript 代码？
当属性组合中包含数组时，函数是否能正常运行并正确展开属性组合？
当属性组合中包含对象时，函数是否能正常运行并正确展开属性组合？
当输入参数 data.base 中包含对象时，函数是否能正常运行并将 data.base 和渲染的属性组合合并为一个对象？

我叹了口气，我在期望什么，果然是这么泛泛的片汤话吗？这玩意还用你告诉我？而且，你这里面还有些不是我想要的啊。唉……心中抱怨了一阵后，我还是不死心，我继续说：

分别准备一些数据

这个要求仿佛打开了潘多拉的盒子，我得到了下面的输出：

以下是可能的数据准备：

空对象：

const data = {};

空的 poly 数组：

const data = {
poly: []
};

包含一个属性组合的数据：

const data = {
base: {
 id: 1,
 name: 'Product A'
},
poly: [
 {
   template_prompt: {
     template: '${name}: ${price}',
     meta: [
       { name: 'color', value: ['red', 'blue'] },
       { name: 'price', value: [10, 20] }
     ]
   },
   id: 1
 }
]
};

包含多个属性组合的数据：

const data = {
base: {
 id: 1,
 name: 'Product A'
},
poly: [
 {
   template_prompt: {
     template: '${name}: ${price}',
     meta: [
       { name: 'color', value: ['red', 'blue'] },
       { name: 'price', value: [10, 20] }
     ]
   },
   id: 1
 },
 {
   template_prompt: {
     template: '${name} (${size}): ${price}',
     meta: [
       { name: 'size', value: ['S', 'M', 'L'] },
       { name: 'price', value: [30, 40, 50] }
     ]
   },
   id: 2
 }
]
};

包含模板变量和 JavaScript 代码的字符串模板的数据：

const data = {
base: {
 id: 1,
 name: 'Product A'
},
poly: [
 {
   template_prompt: {
     template: '${name}: ${price + tax}',
     meta: [
       { name: 'color', value: ['red'] },
       { name: 'price', value: [10] },
       { name: 'tax', value: [2] }
     ]
   },
   id: 1
 }
]
};

包含数组和对象的属性组合的数据：

const data = {
base: {
 id: 1,
 name: 'Product A'
},
poly: [
 {
   template_prompt: {
     template: '${name} (${color.name}): ${price}',
     meta: [
       { color: { name: 'red', code: '#ff0000' }, price: [10] },
       { color: { name: 'blue', code: '#0000ff' }, price: [20] }
     ]
   },
   id: 1
 }
]
};

包含属性值为数组，但未包含数组元素的属性组合的数据：

const data = {
base: {
 id: 1,
 name: 'Product A'
},
poly: [
 {
   template_prompt: {
     template: '${name} (${color}): ${price}',
     meta: [
       { color: ['red'], price: [10] },
       { color: ['blue'], price: [20] }
     ]
   },
   id: 1
 }
]
};

包含模板变量为属性值的数据：

const data = {
base: {
 id: 1,
 name: 'Product A'
},
poly: [
 {
   template_prompt: {
     template: '${props.name}: ${props.price}',
     meta: [
       { props: { name: 'Product B', price: 30 } }
     ]
   },
   id: 1
 }
]
};

包含 render_string_template 函数中 console.log 调用的数据：

const data = {
base: {
 id: 1,
 name: 'Product A'
},
poly: [
 {
   template_prompt: {
     template: '${name}: ${price}',
     meta: [
       { name: 'color', value: ['red', 'blue'] },
       { name: 'price', value: [10, 20] }
     ]
   },
   id: 1
 }
]
};
console.log(render_my_yaml_dsl(data));

包含 expand_attributes 函数中未包含数组的属性组合的数据：

const data = {
base: {
 id: 1,
 name: 'Product A'
},
poly: [
 {
   template_prompt: {
     template: '${name} (${color}): ${price}',
     meta: [
       { color: 'red', price: [10] },
       { color: 'blue', price: [20] }
     ]
   },
   id: 1
 }
]
};

这一刻，我仿佛听到了什么出现裂纹的声音，是我的饭碗吗^_^。

我曾经愚蠢的以为，当我们有了ChatGPT这么强大的工具后，我们只需要写测试就可以了，让他去写实现，而我没有发现这个逻辑里面一个愚蠢的漏洞，一个AI都能写实现了，为什么他写不了测试呢？反过来讲，有很多客户问我有没有自动生成自动化测试的工具，因为他们不想写测试，现在也一样尴尬了。好消息是，有，坏消息是，实现他也能写。

激动了一会，我渐渐冷静下来了，没事没事，这测试没法直接用啊，对吧，你看这测试难道还能扔给一个框架让他自动运行吗，那不是还要写一个专用框架………………想到这，我意识到……好像……我在第一篇的时候干过这事……然后我怀着忐忑的心，写下了下面的prompt：

我们的文件夹结构如下所示

.
├── index.js
└── test
├── cases
│   ├── 1.input.json
│   ├── 1.output.json
│   ├── 2.input.json
│   ├── 2.output.json
│   ├── 3.input.json
│   ├── 3.output.json
│   ├── 4.input.json
│   └── 4.output.json
└── index.js

index.js 是一个函数，大概如下:

module.exports = function render_my_yaml_dsl(data){
//....
}

test/cases下是所有的测试数据，input和output为一组，比如1.input.json存储了一个测试的描述和given数据，1.output.json存储了一个测试的expect数据。两者在.input或.output之前的字符串完全相等为一组。 input.json数据结构为：

    {
    "desc": "测试用例描述",
    "data": { //具体的测试数据
            }
    }

output.json则全部为具体的测试数据基于这个文件夹结构写一个测试框架，放在test/index.js里，要求：

可以遍历test/cases下的文件，分组执行且互相不干扰，也就是其中一组失败了也会继续运行下一组，只是会打印出错误信息。

可以在上层文件夹执行node test来执行

读取文件的fs，要使用const fs = require('fs/promise')引入。

用assert库进行断言

每执行一个测试，要打印一个提示，提示的部分内容要来自input.json 中的desc 给出这个代码

然后我得到了下面的代码：

可以使用以下代码实现测试框架：

const assert = require('assert');
const fs = require('fs/promises');
const path = require('path');
const render_my_yaml_dsl = require('../index');
const testDir = path.join(__dirname, 'cases');
async function runTests() {
    const files = await fs.readdir(testDir);
    for (const file of files) {
        if (!file.endsWith('.input.json')) {
            continue;
        }
        const caseName = path.basename(file, '.input.json');
        const input = await fs.readFile(path.join(testDir, `${caseName}.input.json`), 'utf8');
        const output = await fs.readFile(path.join(testDir, `${caseName}.output.json`), 'utf8');
        const { desc, data } = JSON.parse(input);
        console.log(`Running test "${desc}"`);
        try {
            const result = render_my_yaml_dsl(data);
            assert.deepStrictEqual(result, JSON.parse(output));
            console.log(`Test "${desc}" passed`);
        } catch (error) {
            console.error(`Test "${desc}" failed`);
            console.error(error);
        }
    }
}
runTests();

解释：

首先引入 assert 和 fs 模块，并且导入需要测试的函数 render_my_yaml_dsl。
定义测试文件夹路径 testDir。
创建一个异步函数 runTests 来遍历测试文件夹下的所有测试用例。
使用 fs.readdir 异步读取测试文件夹下的所有文件，然后遍历文件数组，只选择以 .input.json 结尾的文件，跳过其他文件。
通过 path.basename 函数获取测试用例的名称，然后使用 fs.readFile 异步读取该测试用例的输入和输出文件，并使用 JSON.parse 解析 JSON 格式的数据。
在控制台中打印正在运行的测试用例的描述 desc。
使用 try...catch 语句运行测试用例，并使用 assert.deepStrictEqual 函数断言测试结果是否与期望值相等。如果测试通过，打印成功信息，否则打印错误信息。
最后调用 runTests 函数运行测试。

这一刻我终于确信，那确实是饭碗出现裂纹的声音。(虽然上面的只有输入，但是后来我让他给出输出，他也给出了，反正测试框架都有了，大不了跑一遍就有了所有的输出了嘛，所以这不是啥大问题。)

有了这个框架之后，我工作流程大概变成了这么个节奏：

告诉他，我要扩展新功能，然后扔给他旧代码，接着告诉他这里是新新功能需要的输入，我期望的输出是什么。边界是什么，现在给我代码。

然后执行新加的测试，

如果新测试不通过，就让他重新生成.

如果新加测试通过了，但是旧的测试废了，就把就废了测试配上代码给他，告诉他代码有Bug，这是以前的输入，期望的输出是什么，你现在的输出是什么，让他改代码。整个过程就很像TDD的红-绿循环，虽然重构没有了，但是红绿循环还是有的。而更过分的是，一开始新功能需要的测试用例我都懒得自己写，我就大概告诉他要搞个什么样的扩展，给他代码和旧得测试用例结构，让他给我写个新的测试用例。然后就给我写出来了。（也不总能很完美，但是就是需要改也比以前快了不知道多少，关键不用去想那些繁琐的细节也是提供了一定程度的情绪价值。）

按照我的工作流程画个人在回路是这样的：

怎么测试驱动ChatGPT编程

以上就是关于“怎么测试驱动ChatGPT编程”这篇文章的内容，相信大家都有了一定的了解，希望小编分享的内容对大家有帮助，若想了解更多相关的知识内容，请关注亿速云行业资讯频道。

怎么测试驱动ChatGPT编程

停下来想一想

想好了，继续出发

相关阅读