您好,登錄后才能下訂單哦!
這篇“怎么測(cè)試驅(qū)動(dòng)ChatGPT編程”文章的知識(shí)點(diǎn)大部分人都不太理解,所以小編給大家總結(jié)了以下內(nèi)容,內(nèi)容詳細(xì),步驟清晰,具有一定的借鑒價(jià)值,希望大家閱讀完這篇文章能有所收獲,下面我們一起來(lái)看看這篇“怎么測(cè)試驅(qū)動(dòng)ChatGPT編程”文章吧。
nodeJS用下面的yaml描繪的數(shù)據(jù)結(jié)構(gòu)得到一個(gè)新的數(shù)組:
base: steps: 10 batch_size: 1 poly: - template_prompt: template: > a cat, ${ chara } ${ facial_expressions } meta: - chara: # 這里改成了數(shù)組 - 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
},
]
要求:
假設(shè)上面的yaml轉(zhuǎn)成json的轉(zhuǎn)換代碼我已經(jīng)寫完了
我需要遍歷poly下的所有的頂層元素
遍歷過(guò)程中,要處理template_prompt元素的子元素:
從template中讀取作為模版。
讀取meta中的屬性,因?yàn)閷傩钥赡苊看味疾灰粯?,是不確定的,所以不能硬編碼。
然后基于meta中的屬性,把template作為 string literal 解析,這個(gè)解析代碼我已經(jīng)有了,假設(shè)名為render_string_template,可以不實(shí)現(xiàn),留一個(gè)函數(shù)接口即可。
要遍歷組合meta中的每一個(gè)屬性組形成一個(gè)數(shù)組,
每一個(gè)屬性組可能只需要看做一個(gè)對(duì)象,當(dāng)且僅當(dāng)每一個(gè)屬性值都為單值
每一個(gè)屬性組可能也需要展開(kāi),當(dāng)且僅當(dāng)任何一個(gè)屬性值有多值,比如 facial_expressions 有一個(gè)值,chara有兩個(gè)值,那么應(yīng)該生成1*2也就是兩組屬性放入這個(gè)數(shù)組中,這個(gè)數(shù)組和template會(huì)被傳入render_string_template函數(shù),最后會(huì)獲得兩個(gè)prompt字符串
將生成的個(gè)prompt字符串?dāng)?shù)組和template_prompt元素之外的其他元素合并成一個(gè)對(duì)象,要求在同一級(jí)別。prompt字符串?dāng)?shù)組有幾個(gè)元素,就會(huì)合并成幾個(gè)對(duì)象,并放入一個(gè)新數(shù)組中,我們稱之為ploys。
繼續(xù)遍歷,直到遍歷完所有頂層元素,所有元素都放入了polys中。polys是一個(gè)一維數(shù)組。
將ploys中的每一個(gè)元素與base中的屬性合成一個(gè)新的對(duì)象,base的屬性展開(kāi)與prompt屬性同級(jí),當(dāng)ploys中的每一個(gè)元素的屬性名與base中的屬性名相同時(shí),覆蓋base中的屬性。這些新對(duì)象組合出的數(shù)組就是我要的數(shù)組
果然就得到了預(yù)期的結(jié)果。
這一個(gè)動(dòng)作,讓我打開(kāi)了思路,用輸入+輸出框住它生成的邊界還是挺好用的。輸入+輸出框住邊界?這不就是測(cè)試嗎?
從我們的體驗(yàn)來(lái)看,確實(shí)啊,ChatGPT生成的是有點(diǎn)不穩(wěn)定?!禩he End of Programming》說(shuō)的沒(méi)錯(cuò),底層確實(shí)有點(diǎn)混亂與瘋狂的味道,起碼不太穩(wěn)定。但這事也就聽(tīng)起來(lái)很嚇人,說(shuō)實(shí)在的,人就比ChatGPT穩(wěn)定多少呢?我這個(gè)人比較粗心大意,我寫代碼的時(shí)候也經(jīng)常腦子一抽,寫出一些事后看自己都想抽自己的腦殘錯(cuò)誤,所以我自打聽(tīng)說(shuō)了TDD,很快就變成了堅(jiān)定地TDD原教旨主義者,沒(méi)有TDD的世界對(duì)我們這種人來(lái)說(shuō)本來(lái)就是混亂與瘋狂的,要說(shuō)駕馭軟件開(kāi)發(fā)過(guò)程中的混亂與瘋狂,那你是問(wèn)對(duì)人了。
那么回顧一下TDD是什么?下面是一個(gè)復(fù)雜版
基本上就是,先寫一個(gè)測(cè)試用例,然后執(zhí)行,得到期望的失敗,什么是期望的失敗呢,比如說(shuō),你寫了一個(gè)add函數(shù),接受兩個(gè)參數(shù),然后你寫了一個(gè)add(1,1),你期望的失敗可能是返回某個(gè)值,他不等于2,實(shí)際你執(zhí)行的時(shí)候呢,報(bào)錯(cuò),說(shuō)add函數(shù)不存在,這就不是你期望的失敗。你要調(diào)整環(huán)境到你期望的失敗,然后開(kāi)始寫實(shí)現(xiàn),寫完實(shí)現(xiàn)再執(zhí)行,如果測(cè)試不通過(guò)了,就接著改實(shí)現(xiàn),直到通過(guò)。如果通過(guò)了,就問(wèn)自己要不要重構(gòu),如果要重構(gòu),就改實(shí)現(xiàn),改完的還要通過(guò)測(cè)試,如果不想重構(gòu)了,那就寫下一個(gè)測(cè)試用例??傊褪沁@么個(gè)往復(fù)循環(huán)的流程。
如果上面那個(gè)復(fù)雜版讓你覺(jué)得很暈?zāi)?,可以看這個(gè)簡(jiǎn)單版:
紅表示測(cè)試執(zhí)行失敗,綠表示測(cè)試執(zhí)行通過(guò),重構(gòu)就不用解釋了。所以永遠(yuǎn)是綠了重構(gòu),重構(gòu)完可能紅可能綠,紅了就讓他變綠。只有變綠后,可以開(kāi)始下一次循環(huán)。
上面這些圖講的是TDD的過(guò)程,我個(gè)人覺(jué)得更核心的是,在實(shí)現(xiàn)代碼的這個(gè)過(guò)程中,你同時(shí)生產(chǎn)了一套自動(dòng)化測(cè)試,他可以在你將來(lái)不管是加新功能還是修Bug還是重構(gòu),都不會(huì)陷入按下葫蘆起來(lái)瓢的窘境。那么在ChatGPT的時(shí)代,這個(gè)方法還能用嗎?總感覺(jué)哪里需要修改一下,不過(guò)沒(méi)關(guān)系,我們先走起來(lái),邊走邊想。
那么既然是TDD,應(yīng)該先寫測(cè)試,但是我實(shí)現(xiàn)都寫完了啊。算了,這也是大多數(shù)項(xiàng)目的現(xiàn)狀,那就先補(bǔ)個(gè)測(cè)試吧。但是補(bǔ)測(cè)試是個(gè)很煩的事情啊,我靈機(jī)一動(dòng),要不……讓ChatGPT給我搞?它能行嗎?誰(shuí)知道呢,試試又不花錢。 于是我就說(shuō):
給下面代碼設(shè)計(jì)一些測(cè)試用例:
module.exports = function render_my_yaml_dsl(data){ const vm = require('vm'); - // 定義一個(gè)函數(shù)用于渲染字符串模板 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; } - // 定義一個(gè)函數(shù)用于展開(kāi)屬性組合 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; }
是的就是這么任性,代碼直接扔給他。然后我得到了下面的回復(fù):
以下是一些可能的測(cè)試用例:
當(dāng)輸入?yún)?shù) data 為空對(duì)象時(shí),函數(shù)是否能正常運(yùn)行并返回一個(gè)空數(shù)組?
當(dāng)輸入?yún)?shù) data.poly 為空數(shù)組時(shí),函數(shù)是否能正常運(yùn)行并返回一個(gè)空數(shù)組?
當(dāng)輸入?yún)?shù) data.poly 不包含任何屬性組合時(shí),函數(shù)是否能正常運(yùn)行并返回一個(gè)包含原始數(shù)據(jù)的數(shù)組?
當(dāng)輸入?yún)?shù) data.poly 包含一個(gè)屬性組合時(shí),函數(shù)是否能正常運(yùn)行并返回一個(gè)包含根據(jù)屬性組合渲染的數(shù)據(jù)的數(shù)組?
當(dāng)輸入?yún)?shù) data.poly 包含多個(gè)屬性組合時(shí),函數(shù)是否能正常運(yùn)行并返回一個(gè)包含根據(jù)所有屬性組合渲染的數(shù)據(jù)的數(shù)組?
當(dāng)模板中的字符串模板包含模板變量時(shí),函數(shù)是否能正常運(yùn)行并渲染模板變量?
當(dāng)模板中的字符串模板包含 JavaScript 代碼時(shí),函數(shù)是否能正常運(yùn)行并執(zhí)行 JavaScript 代碼?
當(dāng)屬性組合中包含數(shù)組時(shí),函數(shù)是否能正常運(yùn)行并正確展開(kāi)屬性組合?
當(dāng)屬性組合中包含對(duì)象時(shí),函數(shù)是否能正常運(yùn)行并正確展開(kāi)屬性組合?
當(dāng)輸入?yún)?shù) data.base 中包含對(duì)象時(shí),函數(shù)是否能正常運(yùn)行并將 data.base 和渲染的屬性組合合并為一個(gè)對(duì)象?
我嘆了口氣,我在期望什么,果然是這么泛泛的片湯話嗎?這玩意還用你告訴我?而且,你這里面還有些不是我想要的啊。唉……心中抱怨了一陣后,我還是不死心,我繼續(xù)說(shuō):
分別準(zhǔn)備一些數(shù)據(jù)
這個(gè)要求仿佛打開(kāi)了潘多拉的盒子,我得到了下面的輸出:
以下是可能的數(shù)據(jù)準(zhǔn)備:
空對(duì)象:
const data = {};
空的 poly 數(shù)組:
const data = { poly: [] };
包含一個(gè)屬性組合的數(shù)據(jù):
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 } ] };
包含多個(gè)屬性組合的數(shù)據(jù):
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 代碼的字符串模板的數(shù)據(jù):
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 } ] };
包含數(shù)組和對(duì)象的屬性組合的數(shù)據(jù):
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 } ] };
包含屬性值為數(shù)組,但未包含數(shù)組元素的屬性組合的數(shù)據(jù):
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 } ] };
包含模板變量為屬性值的數(shù)據(jù):
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 函數(shù)中 console.log 調(diào)用的數(shù)據(jù):
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 函數(shù)中未包含數(shù)組的屬性組合的數(shù)據(jù):
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 } ] };
這一刻,我仿佛聽(tīng)到了什么出現(xiàn)裂紋的聲音,是我的飯碗嗎^_^。
我曾經(jīng)愚蠢的以為,當(dāng)我們有了ChatGPT這么強(qiáng)大的工具后,我們只需要寫測(cè)試就可以了,讓他去寫實(shí)現(xiàn),而我沒(méi)有發(fā)現(xiàn)這個(gè)邏輯里面一個(gè)愚蠢的漏洞,一個(gè)AI都能寫實(shí)現(xiàn)了,為什么他寫不了測(cè)試呢?反過(guò)來(lái)講,有很多客戶問(wèn)我有沒(méi)有自動(dòng)生成自動(dòng)化測(cè)試的工具,因?yàn)樗麄儾幌雽憸y(cè)試,現(xiàn)在也一樣尷尬了。好消息是,有,壞消息是,實(shí)現(xiàn)他也能寫。
激動(dòng)了一會(huì),我漸漸冷靜下來(lái)了,沒(méi)事沒(méi)事,這測(cè)試沒(méi)法直接用啊,對(duì)吧,你看這測(cè)試難道還能扔給一個(gè)框架讓他自動(dòng)運(yùn)行嗎,那不是還要寫一個(gè)專用框架………………想到這,我意識(shí)到……好像……我在第一篇的時(shí)候干過(guò)這事……然后我懷著忐忑的心,寫下了下面的prompt:
我們的文件夾結(jié)構(gòu)如下所示
. ├── 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 是一個(gè)函數(shù),大概如下:
module.exports = function render_my_yaml_dsl(data){ //.... }
test/cases下是所有的測(cè)試數(shù)據(jù),input和output為一組,比如1.input.json存儲(chǔ)了一個(gè)測(cè)試的描述和given數(shù)據(jù),1.output.json存儲(chǔ)了一個(gè)測(cè)試的expect數(shù)據(jù)。兩者在.input或.output之前的字符串完全相等為一組。 input.json數(shù)據(jù)結(jié)構(gòu)為:
{ "desc": "測(cè)試用例描述", "data": { //具體的測(cè)試數(shù)據(jù) } }
output.json則全部為具體的測(cè)試數(shù)據(jù) 基于這個(gè)文件夾結(jié)構(gòu)寫一個(gè)測(cè)試框架,放在test/index.js里,要求:
可以遍歷test/cases下的文件,分組執(zhí)行且互相不干擾,也就是其中一組失敗了也會(huì)繼續(xù)運(yùn)行下一組,只是會(huì)打印出錯(cuò)誤信息。
可以在上層文件夾執(zhí)行node test
來(lái)執(zhí)行
讀取文件的fs,要使用const fs = require('fs/promise')引入。
用assert庫(kù)進(jìn)行斷言
每執(zhí)行一個(gè)測(cè)試,要打印一個(gè)提示,提示的部分內(nèi)容要來(lái)自input.json 中的desc 給出這個(gè)代碼
然后我得到了下面的代碼:
可以使用以下代碼實(shí)現(xiàn)測(cè)試框架:
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 模塊,并且導(dǎo)入需要測(cè)試的函數(shù) render_my_yaml_dsl。
定義測(cè)試文件夾路徑 testDir。
創(chuàng)建一個(gè)異步函數(shù) runTests 來(lái)遍歷測(cè)試文件夾下的所有測(cè)試用例。
使用 fs.readdir 異步讀取測(cè)試文件夾下的所有文件,然后遍歷文件數(shù)組,只選擇以 .input.json 結(jié)尾的文件,跳過(guò)其他文件。
通過(guò) path.basename 函數(shù)獲取測(cè)試用例的名稱,然后使用 fs.readFile 異步讀取該測(cè)試用例的輸入和輸出文件,并使用 JSON.parse 解析 JSON 格式的數(shù)據(jù)。
在控制臺(tái)中打印正在運(yùn)行的測(cè)試用例的描述 desc。
使用 try...catch 語(yǔ)句運(yùn)行測(cè)試用例,并使用 assert.deepStrictEqual 函數(shù)斷言測(cè)試結(jié)果是否與期望值相等。如果測(cè)試通過(guò),打印成功信息,否則打印錯(cuò)誤信息。
最后調(diào)用 runTests 函數(shù)運(yùn)行測(cè)試。
這一刻我終于確信,那確實(shí)是飯碗出現(xiàn)裂紋的聲音。(雖然上面的只有輸入,但是后來(lái)我讓他給出輸出,他也給出了,反正測(cè)試框架都有了,大不了跑一遍就有了所有的輸出了嘛,所以這不是啥大問(wèn)題。)
有了這個(gè)框架之后,我工作流程大概變成了這么個(gè)節(jié)奏:
告訴他,我要擴(kuò)展新功能,然后扔給他舊代碼,接著告訴他這里是新新功能需要的輸入,我期望的輸出是什么。邊界是什么,現(xiàn)在給我代碼。
然后執(zhí)行新加的測(cè)試,
如果新測(cè)試不通過(guò),就讓他重新生成.
如果新加測(cè)試通過(guò)了,但是舊的測(cè)試廢了,就把就廢了測(cè)試配上代碼給他,告訴他代碼有Bug,這是以前的輸入,期望的輸出是什么,你現(xiàn)在的輸出是什么,讓他改代碼。 整個(gè)過(guò)程就很像TDD的紅-綠循環(huán),雖然重構(gòu)沒(méi)有了,但是紅綠循環(huán)還是有的。 而更過(guò)分的是,一開(kāi)始新功能需要的測(cè)試用例我都懶得自己寫,我就大概告訴他要搞個(gè)什么樣的擴(kuò)展,給他代碼和舊得測(cè)試用例結(jié)構(gòu),讓他給我寫個(gè)新的測(cè)試用例。然后就給我寫出來(lái)了。(也不總能很完美,但是就是需要改也比以前快了不知道多少,關(guān)鍵不用去想那些繁瑣的細(xì)節(jié)也是提供了一定程度的情緒價(jià)值。)
按照我的工作流程畫(huà)個(gè)人在回路是這樣的:
以上就是關(guān)于“怎么測(cè)試驅(qū)動(dòng)ChatGPT編程”這篇文章的內(nèi)容,相信大家都有了一定的了解,希望小編分享的內(nèi)容對(duì)大家有幫助,若想了解更多相關(guān)的知識(shí)內(nèi)容,請(qǐng)關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。