vitest如何做前端UI测试

嗨，欢迎回来，那么在开始本节内容之前呢，我先带各位解决一个小问题， 目前我们编辑测试的时候呢，所有的测试的内容呢，都是展示在终端中的，对吧？不管是我们测试的文件内容，还是测试错误的一些信息呢，都需要我们在终端中进行查找，那么相信经过前一节我们纠正过一个错误之后呢，大家就会发现，在终端中去 查看问题并解决问题呢，其实是一件非常麻烦的事情啊，因为终端对于我们来说其实并不是特别的好看啊，在里面查找问题和解决问题呢，也比较麻烦， 那有没有什么更好的方法呢？毕竟现在都已经二零二五快二零二六年了，是吧？那么解决方法呢，其实很简单，我们的 vtes 的 呢，作为一个比较先进的工具，它其实给我们提供了一个自动生成的带 ui 界面的一个测试的 一个网页，只是呢我们需要手动的去开启这样一个功能。我们来到 vtest 的 官网，应该是 guides 下面的 vtest ui 这个地方， 那么可以看到我们的 vtest 呢，其实给我们提供了这样一套 ui， 只是呢我们还没有安装并且起用它，我们要先安装这样一个 vtest ui， 手动的安装一下， 然后呢需要在我们运行测试的这个地方呢，添加这样一个带有 ui 的 flag， 也就是这样一个 ui 选项，或者这个选项来到我们的运行测试的脚本这个地方，也就是 package json， 在 这里找到我们的 vite， 这里的 test 后面加上我们的 ui 就 可以了， 此时我们在运行 test 这样一个脚本，它就会自动的在我们的浏览器中打开这样一个在线的网页，那在这个网页中呢，我们就可以查看每一个测试的报告用时以及测试的代码，甚至还能够查看这个测试文件与我们的 这个测试组建之间的一个依赖关系，可以看到非常的简单，对吧？甚至还能够看到个插件和我们组建的 这个关系啊，甚至还能够调整我们的免按模式啊，可以说开发体验基本上是拉满的，那么之后呢，我们就会基于这样一套 vitis 给我们提供的 ui 来进行测试的学习，这样的话我们不管是查找问题还是进行测试的话，就会更加的方便，对吧？那么今天我们要干什么啊？这一节呢，我们要 进行第二个组建的测试，也就是我们的 components 下面的 select color 这样一个组建的测试，那么我们看一下这个组建干了什么的？我们来运行我们这样一个应用， 打开应用，那么当前这样一个应用中的 select 部分呢，就是用来修改下面这个圆圈，它的文字颜色的就是里面这个 high， 它的颜色可以看到这里有白色，黑色还有 橙黄色，对吧？那么我们要测试的部分呢，就是先判断这样一个 label 标签它是否存在，还有这样一个 select 元素它是否存在。把这两个测试完成之后呢？ 我们再来判断一下，我们用户点击这样一个 select 之后，它里面的这样一些 select 数量是不是正确的，是不是有对应的三个选项，以及每个选项它的值是否是一致的，并且它点击之后呢，这样一个 select， 它的整体的值是否发生了变化？ 我们大概就做这样一些测试，所以呢，总体其实分两个部分，一个是静态的渲染测试部分，另一个呢就是和用户交互的部分，对吧？那我们先来完成第一个比较简单的部分，我们先把测试跑起来，我们待会就利用它的这样一个热存载，让它自动的 运行测试就行了。那我们接下来的话呢，复制这样一个我们要测试的组建的名字，来到我们的 test 目录下，来到 components 新建一个测试文件 test t s， 在 这里呢，我们还是需要手动的去导入这样一些我们要用到的东西嘛。我们来看一下，正常的话，我们这个地方需要导入这样一个来自 testing library view 的 这样一 random， 还有 screen， 对 吧？还有 和我们用户交互的这样一个 user event， 那 这些手动导入的话，每次都要做，其实很麻烦的。这里的给各位介绍另一个插件，它叫做 testing library snippets， 就是 和 testing library 这样一个库相关的这样一些简单的代码缩写片段。在下面这个 snippets 部分，我们可以找到这样一些我们可以利用的缩写。首先呢是 itv， 就是 import view， 那 么它就可以自动地导入我们想要用到的 random screen， 还有这里的 itue， 也就是和 user event 相关的东西，甚至呢它还可以直接导入这个 itr， 也就是和 react 相关的。好，那我们截个图， 我们只截我们需要的部分，来到我们的新的测试文件中， itv， 这样的话就自动导入了和 testing library view 相关的，然后呢是 i t u e， 也就是和 user event 相关的啊，这样的话就比较轻松了，对吧？那么接下来我们来编写我们的测试，首先呢，我们要对我们的测试做一下分组，我们在对顶上使用我们的 describe 进行分组，这个我们就写上我们这样一个测试的组建名就可以了。然后呢，第一个组别 就是和我们的渲染测试相关的 random test。 然后第一个测试，它叫做 shoot random the select element correctly。 那 么这个测试呢，我们首先需要渲染我们的组建，那我们这个组建呢，叫做 select color 渲染完成，我们通过 screen 来查找我们的这样一个，嗯， select 元素。我们这样一个 select 元素呢，就是一个普通的 select 元素啊，它没有什么额外的属性，但是我们在通过 get by row 进行查询的时候，我们该传什么东西进去呢？ 我们难道就直接写 select 吗？那么很明显是没有 select 的 这样一个选项的，那它到底叫什么角色呢？我们如果要知道一个 html 元素，它对应的角色是什么，我们是需要来到 mdn 文档来看一下。我们在 google 搜索 select html 元素的这个部分的文档，也就是直接来到 select 这样一个元素，在 mdn 的 官方文档 在右边找到 technical summary， 也就是技术总结这个部分，有一个部分呢需要注意就是这里的 implicit area role， 也就是它隐式的这样一个 area 角色，那么 area 角色其实就是用于和我们的语义化标签相关的内容的，那这它其实就明确的介绍了 combo box with no multiple attribute and no size attribute greater than one otherwise list box。 也就是当我们这样一个 select 元素，它没有 multiple 这样一个属性，也没有 size 这个属性的时候呢，它就是为 combo box， 如果有的话呢，它就是为 listbox。 那 么很明显，我们这样一个 select 元素，它上面什么多余的 html 属性都没有，所以呢，我们就把它叫做 combo box。 我 们来试一下 combo box， 获取我们的 select。 接下来就是 expect select to be in the document。 我 们来看一下测试，测试通过了是吧？应该是在这个地方，这里测试通过，我们再看一下测试代码，和我们写的是一模一样的。那么接下来来完成第二个测试，我们直接复制这里呢应该是 label， 然后这里是 with correct text， 我 们要通过对应的文本内容来查询这里的 label 标签是否存在，所以呢，这里我们使用 get by text。 对应的文本内容的话，我们使用正则表达式来到我们的 select color， 复制这个文本内容，就是 text color 粘贴进去，获得我们的 label， 判断一下这个 label 标签是否存在就可以了。再次来到我们的测试，我们手动运行一下没什么问题，是吧？这两个简单的渲染测试呢，我们就已经完成了， 那接下来的话呢，我们就要完成和我们的用户交互相关的部分，那我们再写一个 describe， 这里写上 user interaction。 这里第一个测试呢，我们就叫做 should should display the correct options should display the options with correct count。 也就是展示正确数量的这样一些 select 选择的这样一些选项，说白了就是点击这里的 select 元素之后，我们期望的是呢，我们的 这个界面中应该出现三个 option 选项，对吧？所以呢，我们要做的事情就是，哎，我们干脆先先渲染，然后呢查询这样一个 select 元素，最后呢，判断一下里面的这个 option 元素的数量，对吧？ 我们直接复印一下刚才的逻辑啊，渲染并且查找这个 select 的 部分呢，我们就不再手写了。然后呢，我们需要点击这样一个 select 元素，我们就要用到我们的 user event， 还记得它该怎么用吗？我们先是需要使用 user event set up 获取一个 user 对 象，对吧？ user， 然后呢，通过 user click 点击我们的 select 元素，并且是要注意这里的 select， 它是一个 promise 函数，所以呢，前面要写上 wait， 整个测试函数要变为一步函数。然后呢，再是 通过我们的 screen 去查找相应的这样一些 option 元素，判断一下它的数量是否正确。那么我们的 option 这样一个 h t 秒标签，它对应的 row 又是多少呢？还是一样啊，来到我们的 m d n， 我 们搜索 option， 来到这个 option element， 它的文档还是在右边找到 technical summary， 找到它的 implicit area row， 那 么可以看到它只有一个选项叫做 option 啊。这里的话就比较简单了， 回到我们的测试文件，还是一样使用 screen get by row option， 对 吧？但是呢，这里其实有一个问题， get by row， 它只能够返回一个 html 元素，那么它返回一个 html 元素，我们又是怎样能够判断我们具体的这样一些 option h t m 元素，它的数量在哪？很明显，我们这里应该查询所有的这样一些 option 元素才对。那么查询所有的 option 元素，我们就不能再使用 get by rule 了，我们要使用另一个方法，那么还记得该使用哪个方法吗？啊，这里我们来到 testing library 它的文档，来到 core api about curious 这里的 types of curious， 那 么可以看到我们使用的 get by， 它只能查询单个的元素，然后查询多个元素，就要在这里使用我们的 get or by。 所以呢，我们把这里的 get by row 改为 get or by row 就 可以了，这样它返回的内容呢，就是 一个元素为 html 元素的这样一个簇。好，我们返回的内容呢，就是 options， 它就是一个簇了。那么接下来我们期望这样一个簇，它的长度为三，那么这里我们使用的匹配器就是 two have length， 写上我们的长度为三就可以了。好，就这么简单。来到我们的测试，这里所有的测试应该是通过的，我手动再来重新运行一下。好，这里的 user interaction 这个部分呢，它就成功的运行了，没有任何问题，对吧？但是呢，这样我们的测试其实还是不够完善的， 我们只是测试了一下里面的 option 它的数量是否正确，但是我们并没有测试这个 option 中间的这样一些 value 值是否正确，对吧？我们也没有测试这个 option， 它在点击之后，整个这个 select 它的值是否会发生改变。所以呢，这里其实我们缺少一些 其他的测试啊。那么这个部分呢，我们就留到下一集再讲，那么本节的内容呢？主要就是带各位了解我该怎样起用我们的 vitus 的 ui， 可以 看到它其实非常的好用，比起我们的这个终端其实是好看多了，以及我们该怎样查询多个 元素，还有我们该怎样去得知一个 html 标签它的 row 为多少？这里我们需要借助官方的 m d n 文档它里面的这个 implicit area row 这个部分。那么以上就是本期视频的所有内容，希望你能关注或订阅我的频道，感谢你的观看，我们下期视频再见！

嗨，欢迎回来，那么这一节呢，我们直接开始上手尝试使用我们的微 test。 那 么需要注意啊，本节我所用到的这样一些写法，还有安装的一些第三方库呢，各位先不要去纠结它们的作用，之后的话呢，我会逐一讲解。 首先呢，我们来到我们的终端，在我的桌面，我新建一个基于 vt 的 react 项目，选择 react， 选择 type script， 进入我们的项目，用 javascript 打开，删掉不必要的 文件，还有一些依赖，这里呢，我们需要删掉和 yes link 相关的东西，暂时不需要使用 yes link。 那 么接下来呢，我们需要在我们的项目中引入我们的 vtest。 这里呢，我们来到我们的这个 vtest 的 官方文档， 在右边，我们找到这里的 adding vtest to your project， 找到相应的报管理器的安装命令。那么这里可以看到 vtest， 它所需的 vt 版本呢，一定是 v 六以及 note 版本呢，一定是 v 二零以上。所以呢，各位在二零二五冬天的这个盛宴节点呢，各位一定不要使用低于这两个版本号的东西了。好的，来到我们的终端安装，我们的 vtest， 安装完之后呢，它会 给出一个简单的例子，那么这里呢，他给的例子呢，是一个 js 文件，那我们完全可以把这个函数呢 复制粘贴写成一个 js 文件，其实是没有任何区别的。那这里呢，我们在 s 二 c 下面，我新建一个文件夹，我叫做 utos， 在 文件夹里新建一个文件，把这个文件叫做 sun js， 那 我叫 sun t s。 粘贴好，这里要传入参数的类型。这里呢，相信各位学过 type script 的 话呢，这个并不是什么很难的东西，对吧？非常的简单。那接下来就重点就是要创建相应的测试文件， 那么可以看到测试文件，它比起上面的这个 g s 文件，它的区别呢？就在于在文件名和 g s 或者说 t s 后缀的中间呢，它多了一个中间的描述词，叫做 test。 那 么这样一个带有 test 字样的文件呢，它就会被 vtest 自动地识别成我们的测试文件。那么下面这里的 tips 可以 看到， by default tests must contain dot test dot or dot specs dot in their file name。 也就是在它们的文件名称中，一定要确保有 test 或者说 specs 这个字样，那么有这样字样的文件内容才会被识识别成我们的测试文件。我们复制这个内容，然后复制这个文件名。那么相应的测试文件呢？我个人是更倾向于把它放在我们的根目录下面一个单独的文件夹内，我叫它 tests。 然后呢，我个人非常倾向于在 tests 文件目录中和我们的 s r c 中间的要测试的文件进行印刷。什么意思呢？我们的 tests 就可以看作是我们的 s r c， 我 们要测试的文件，它位于 utos 这个文件目录下面，所以呢，我们的 tests 这个文件夹里面也要有一个叫做 utos 的 文件目录，创建这样一个新的文件，这个测试文件用 t s 结尾，那么可以看到，只要它中间带有 test 的 这个字样，那么左边我这个文件图标主题下面的它左边的 图标就会变成这个试管一样的，这个图标就表示我们当前文件它是一个测试文件，包括如果把中间的这个 内容变成 specs， 它也是会识别成一个测试文件，但我个个人的话，更推荐各位使用 tests， 这样的话更加的直观，这样所有人都知道这是一个测试文件，仅凭文件名就可以识别出，对吧？直接粘贴刚才我们复制的这样个测试代码，那么这里的 sum j s 呢？我们要 给它改一下路径 s r c 下的 utools， 下面的 song 一 些就绪。那么我们需要在我们的 package json 这里添加一个叫做 test 的 脚本，这个脚本做的事情非常的简单，就是使用这个 vtest 的 命令复制这个 test 脚本，来到我们的 package json 添加这个脚本。好的，那我们接下来来运行这个脚本，那这里呢，我们使用的这个包管器是 p n p m， 我 的版本呢还算是比较新吧，十点一四点零，所以呢， 在这个版本中，我们运行任何的命令都不再需要像之前那样 p n p m wrong， 后面再加上接上这个脚本名称了，我们直接 p n p m 接上我们要运行的脚本名称就可以了，直接运行 test。 那 么很快啊，这里的测试呢就已经运行完成了，它会先指示我们 所需要测试的这样一些文件，然后呢，只是这样一些测试文件中对应的测试内容，那么这里的内容是什么呢？ 这里的内容就来自我们测试文件中这个 test 函数中的第一个参数，这个第一个参数就表示当前这个测试它的名字是什么？中间接受的参数呢？都是字母串，那么这个字母串会原封不动地打印在我们的 vtest 测试报告中， 那么这里有相应的用时，可以看到用时是零毫秒，一毫秒，对吧？因为我们这个测试非常简单嘛，就是简单的调用一下这个加法，判断一下它的数值，这里可以看到它的这个 测试的内容呢，首先是调用我们要测试的这个函数，然后传入上的内容，那么这个函数会返回一个数字，对吧？那么这样一个数字呢，我们会希望它等于多少？所以呢，这里会用到一个函数叫做 expect， 它就是期望的意思。这里的 expect 还有 test， 它都是来自微 test， 它内部的工具，我们要期望它干什么呢？或者说期望它等于什么呢？后面就要添加上对应的这样一些工具函数，这样一些工具函数呢，我们一般都把它叫做 measure， 也就是 expect result。 measure 啊，一般我们都把它叫做 measure， 那 么这里这个 measure 叫做 to b， 那 除了 to b 呢，其实还有非常多的 measure， 这里我们可以去 我们的 vtest 的 官方文档啊，可以看到就在它的 vtest 的 官方文档的 api 这个部分，我们点进来左边找到 expect， 期望这个部分，右边呢就能够找到各种各样的这样一些 measure， 那 么这些 measure 呢，只是非常基础的 measure， 我 们可以通过它来判断一下我们 对应的函数它的返回值，比如 to b， 就是 是否为多少，如果是字母串的话，一般要调用 to equal， 那 么这里它的内容非常非常的多，各位不要去一个一个记，我们后面的话呢，会根据我们的项目需求来逐步的使用这里的这样一些 match 匹配器， 各位先不要纠结它具体的用法，那么这里呢，我们写了一个最简单的测试，但是呢可以看到当前的这个测试呢，其实和我们的 react 或者说前端没有任何的关系， 我们只是测试一个用 type script 编写的工具函数，当然你从这里可以看到我们的 vtest， 它其实不止可以测试前端啊，它也可以测试后端的逻辑，对吧？ 那么接下来的话呢，我们要来尝试一下在我们的 react 项目中呢，实际的使用 vtest 测试我们的 react 组建，那么这里该怎么做呢？首先我们先退出这个 vtest， 这个 vtest 的 测试呢，它是会自带热存载的，所以呢只要我不把这个终端关掉，或者说不把这个 vtest 的 测试退出的话，它是会一直运行的，只要我这里修改了任何一点东西，比如我这里期望它为四，那么很明显这个会报错，保存的一瞬间，下面的测试呢就会重新运行， 并且指示我哪里出了问题啊，这是 vtest 的 非常好用的一点，并且可以看到速度非常的快，对吧？那么这里我们输入 q 就 可以退出了，或者说你强制退出用 ctrl c 也是一样的。 那么这里的话呢，我们要测试的内容呢，就来自我们这个项目最开始创建的时候，给我们提供的这样一个叫做 app 的 组建。我们来看一下我们这个项目，我们使用 app 命令看一下我们当前这个项目的样子， 当前这个项目呢是一个非常经典的使用 wit 创建的模板项目，这个模板项目中呢有一个 he 标签，有一个按钮，那我们要判断这样一个 app 组件它是否存在的话呢，就是判断我们这个组件渲染在页面之后，它是否存在一个 he 标签的 这个元素，并且是否存在一个 button 按钮，对吧？仅凭这两点我们其实就能已经能够判断我们当前这个组件是否成功渲染了。 那具体在我们的 vtest 的 测试中该怎么做呢？那我们先创建相应的测试文件，我们这里的 app t s x 呢，它就位于 s r c 目录下面，对吗？所以呢，我们直接在 test 文件目录下面呢新建一个相应的测试文件，我们叫它 app test t s x 啊，注意是 t s x， 因为我们需要在我们的代码中呢渲染我们的 react 的 组建，那么渲染 react 的 组建就必须要在我们的代码中写上 jsx 的 逻辑，就是这样，对吧？ 所以呢，我们的文件后缀一定要是 t s x， 这样它才能够使用我们的 jsx 语法。那么接下来的话呢，我们 照漫画虎试一下，我们直接复制粘贴，那么这里的导入我们肯定就不能这么写了，我们的测试的话呢，这里就需要改一下里面的这样一些内容，那么首先这个 expect 里面的内容呢，就是 我们要期望某一个元素存在，所以呢，这里 expect 里面要传入的就是我们要查询的元素，那么这个元素该怎么查询呢啊？这里呢我们 进行测试的过程呢，是基于虚拟的这样一些动环境来进行测试的，所以呢，我们要安装一些第三方的工具来模拟我们的这个浏览器环境，也就是实现虚拟的动环境。那么这里呢，各位还是不要去纠结这里我用到了什么库，各位先跟着我做尝试一下，好吧， 我们需要安装这样一些第三方库，第一个呢是叫做 testing library 下面的 react， 第二个呢是 json， 这个就是用来模拟我们的这个虚拟环境的，那么第三个呢就是 testing library json， 它就是提供 matured， 那 么刚才我们 可以看到在 vtest 的 文档中已经有了 match， 对 吧？那么为什么还需要借用它来提供 match 呢？因为它提供的这样一些 match 匹配函数的话呢，是专门针对前端的这样一些组建的，所以呢，我们需要它来提供我们的 match， 这里所有的这样一些三个第三方依赖呢，都需要作为这个开发依赖进行安装回车。然后呢，在我们的测试这里呢，我们首先需要将我们的组建，也就是这个 app t s x 进行渲染，对吧？那么渲染该怎么做呢？那渲染的， 呃，对应的英文单词很明显应该是 random， 对 吧？那我们的 random 呢，就来自刚才我们安装的其中一个第三方依赖 testing library react， 它里面就提供了一个叫做 random 函数，那就可以通过它来渲染我们的 react 组建，那么我们去导入我们要测试的这个组建，这里写上相对路径 s r c 下面的 app。 好 的，渲染之后呢，我们要判断我们渲染出来的这个组建中有没有相应的内容，对吧？ 么这里的查找相应的内容是否存在的话呢？其实就和我们之前使用最简单的 javascript 进行 do 操作，或者说 do 查询是一模一样的，我们来看一下我们这个组件，我们这个组件一定要判断它是否存在，我们要做的就是查询这里的 he 标签它是否存在，还有这个 button 按钮它是否存在，那这里的话呢，我们要 借用这个第三方库中的另一个东西叫做 screen， 也就是屏幕，我们借用屏幕这个对象调用它其中的 get by row 方法，当然其中它可以有其他各种各样的方法，但这里呢，我更推荐使用 get by row， 也是通过这个标签的角色来查询。那么首先我们查询的是 这个 head 标题，对吧？那么 head 标题它的对应的角色呢？就是 heading， 可以 看到这里有是有代码提示的，那么它返回的内容呢？是一个 html 元素，我们写上 heading element， 那 么把我们查询到的这样一个 heading element 这个元素呢？把它放在我们的 expect 这个期望函数中，那么我们期望这样一个标标题元素它是存在的，那么这个存在又该怎么表示呢？这里的就需要使用我们的第二个第三方库， 它叫做 testing library js， 可以 看到我这里并没有从它中间解构出任何的东西，对吧？并且这里它还需要指定一下，它是使用 vtest 相应的工具， 那么这个第三方库呢，就会提供我们所需要的这个 match， 也就是匹配器，那么这里的匹配器把它叫做 to be in the document， 其实就是存在于我们的文档中，对吧？那么这样写其实还不够，我们需要配置我们的 vtest， 让它知道我们是在虚拟的动环境中去运行这个测试的，因为我们需要指定我们的这个 app 组件在怎样的环境下进行渲染，对吧？那么这里的话呢，来到我们的 a test 的 文档，来到这里的 configuring a test， 那 么在下面我们可以找到这样一个简单的说明， if you are already using vita test property in your vita config。 如果你已经在使用 vita 的 话呢，那么只需要在 vita 的 配置中添加这样一个叫做 test 的 这样一个属性就可以了，那我们复制这个内容，那么这里其实还不够。如果你和我一样使用的是基于 type script 的 项目的话呢？ 那么在将我们的 vita test 和 vita 配置合二为一的时候，一定要在上上面多加入这样一个 reference， 这样的话我们的配置才能够在 vt 配置中生效。然后在下面接上一个 test 的 属性，那么这个 test 的 属性我们该怎么写呢？那我们在下面找到 project support， 那 么这里呢，我们需要配置我们测试的环境，也就是这个部分 environment， 我 们先写上，看看它里面有哪些选项啊？ environment， 来我们看一下它里面一共有四个选项，对吧？那么我们当前的环境呢，是需要模拟我们的这个 真实浏览其中的动环境，对吧？那么具体用什么东西来模拟的话呢，就取决于我们用什么样的 d 三八酷，那么刚好我们刚才安装的其中一个 d 三八酷呢，就叫 jesdone， 我 们就使用它就可以了，当然如果你不想用 jesdone， 你 也可以使用 happyone， 它们两者作用是差不多的， 只不过 jesdone 呢，更加的成熟一些，就这么简单，我们不需要做额外的配置了，这样配置完成之后，我们再来 进行我们的测试。那么此时可以看到，我们其实已经有了两个测试文件，一个是 sum test t s， 一个是 app test t s x， 那 么它们两个文件中呢？都只有一个测试，对吧？我们可以在一个文件中写多个测试啊，比如把这个 test 我 再复制一份， 我待会再写其他的，并且这个测试的名字呢？啊，这个测试的名字我要改一下， heading element shoot in the document。 我 们把测试的名字改一下，这样的话好区分一些。我们来重新运行这样一个 test 的 命令，运行我们的 v test 的 测试，看一下效果。那此时呢，我们的两个测试都已经通过了，非常的简单，对吧？速度呢，其实和刚才并没有 什么态度的区别。那么有了第一个简单的成功测试呢，我们接下来就可以尝试。第二个就是和刚才我所做的东西一样，我们来查询这样一个按钮，它是否存在于我们的这个文档中，那写法呢？其实和刚才是一样的， 我们复制这一段，我们把这个 row 从 heading 改为 button， 这些都是有提示的，各位不用去担心。然后呢，这里写上 button element， 复制一下，把这里的 heading 改为 button elements 保存。那这里呢，我们测试呢，又成功地通过了，并且可以看到它这里只提示了 one pass。 啊，这是为什么呢？明明我们有两个测试文件呢，为什么它只运行了其中一个测试呢？这是因为我们的 vtest， 它有自动的缓存，它能够检测到我们哪些测试文件做了修改，哪些没有做修改，那么它只会将我们 做了修改的这样一些测试文件，也就是这里的 tests app t s x， 它只会将已经被修改过的这样一些测试文件重新的运行，它不会再去重复的运行之前没有被修改的这样一些已经通过的测试了，那这一点就非常的智能，能够节省大量的时间，对吧？那么 以上呢，就是本节关于 vtest 的 这样一个简单的说明啊，再强调一点，本节所有的内容的话呢，各位都不要去纠结啊，我只是简单的带各位看一下一个最简单的基于 vtest 测试 react 项目的这样一个测试内容呢，该怎么写？只是让各位有一个最初的印象， 我们之后所学习的内容的话，肯定会在这之上做一些优化的，所以呢，各位千万不要花太多的精力去思考我本节讲的东西，因为之后的写法呢，可能和及这一节的写法截然不同。那么以上就是本期视频的所有内容，希望你能关注或订阅我的频道，感谢你的观看，我们下期视频再见！

大家好，我是 mary， 那 今天呢来给大家看一下 treo 最近发布的功能 skill 的 一个应用，那这里呢，我们还是以这个将这个 figma 的 ui 设计图呢去转化成前端代码的方式来去做一个实践上的给大家展示。比如说这里呢是我们一个前端的 figma 的 一个设计稿， 然后呢这个是我通过啊 treeo 的 缩模式加上啊 skill 和 mcp 的 方式呢去生成的一个前端网站代码。看到这是网站代码呢，呃，只需要是只需要根据它一个页面呢就生成一个比较啊不错，比较完整的一个前端代码，可以看到这个页面呢，它支持这个 分类，那底部导航呢，是可以进点击的，然后一个搜索，然后呢整个交互层面的话，其实跟我们实际的开发一个前端是一样的，但是这个只是通过啊十多分钟就做好了这样一个前端，并且呢一键的部署到了这个域名上面，是可以直接访问的，而且就是我们通过 solo 模式生成的效果。 那这里就提到就是输入模式呢，也是在输入好的时候发布了支持的 skill 的 方式，那这里可以给大家解释一下什么是 skill skill 可以 理解成就是一种啊 a 阶的智能体的一个专项的一个工具包，它比这个我们去直接定义规则更加的 丰富，更加的专业性更强。我们一个一个规则啊，我们一个弱式定义的话，可能定义的范围太大，不够灵活，但是我们如果说定义成 skill 的 方式的话，它相当于是一个专项的一个 啊专更专业的一个智能题啊，此智能题它通过这题规范生成一个智能题，那更加能专注他领略的一些任务，它的使用背景呢，就是它能去 按需的进行调容，它会去呃可以把 skill 能力进行赋用，它可以将这个专业知识打磨成可赋用一些指令 啊，比如，然后呢，它还可以去赋能它的一些新的功能，然后可以将这些重复的工作哈就流程化多工作去变成一些附用可附用的一些工作流程，然后呢还有一些操作性 创建 skill 呢，比较简单啊，就肯定可以通过对话方式让它去让这个 tree 来帮你创建 skills， 然后创建之后呢，大家可以看一下创建之后呢， 比如说我们在这个右侧的这个编辑器里面就有对应一个 skills 文档，就在 tree 目录下有个 skill 文档可以看到，这里呢， 我们有一个 fig 码，就可以将这个 fig 码转成 skill 的 一些规范，就是将 fig 码转前端一些规范，比如说这个工作流程啊啊成功秘诀还有呢，这里这里我们是什么？这里是一个 啊制作一个前端移动端的响应页面开发的规范，这规范呢，其实是我们根据啊它生成的代码之后呢回复的一个总结，总结之后让他去 在这个开发过程中总结出了这样的一个啊 skill 的 一个能力，然后呢，它会基于你当前项目风格去帮你去设计这样的一个 skill。 那 后续如果说我们要开发同一个风格的网站的话，就可以借助于它这个 skill 我 们沉淀下来一个 skill， 包括像于说我们要开发 react 项目前的项目的时候，这个 react 前的项目，它定义的一个前端的一个规范啊，等后续我们说开发同样的话，就可以附用这个 skill， 也是 skill 的 在开发之后的一个沉淀。 那前期呢，我们可以给它定义成基础的 skill， 那 其实就相当于是我们给它定义了一些专业技能的 skill， 它会这个它们品呢，会根据它的需求去选择对应，根据它描述选择对应的 skill 来去作为它的一个提示词啊，可附用的提示词， 这是它的设计规则啊，这里也可以自动通过手动方式去创建 skill， 比如说啊，它主要是设置创建的 skill 名称描述，还有它的一个指令 啊，这个目前呢确有一些知识了，这里呢我们可以看一下我们之前的对话的内容，那这是我通过这个 solo 模式的这个啊 build 方式啊，去生成这样的一个前台网站啊，可以看到我们第一次呢是让它去根据这样的一个 skill 文件，它就会帮我们创建一个 skill 文件，它就会创建一个从这个程序里面创建这样的一个啊 skill 文件创建好之后，它会告诉你这个它有 skill 能力， 然后啊我我们这里，然后就转成转成中文。还有第二就是我们要去啊，去基于这个 figma 设计稿去设计一个中文的前台网站，那可以看到它就是 我们需要去指定我们对应的一个 figma 的 数据，那这里需要注意，我们再去使用 shift 模式的时候，它这里右侧呢是可以添加这个 figma 的 这个工具的，那非看我们首先需要做登录，登录之后呢， 对，之后呢对应的我们就可以到跳转到我们的飞克马设计导，之后呢我们就可以让添加对话，这个地方我们可以选择页面，让添加对话的话，它就可以生成这样的一个，一个是缩略图，一个是它原始的这个数据文件，比如它 cs， cs， cs， cs 或者前端的数据文件。然后呢这个 大媒体呢，我们选择的是 gmail 三 pro， gmail 三 pro， 然后呢它就会帮我们去根据这样的一个 facebook 社群生成一个前端的一个网站。大家需要注意点就是它首先第一步呢，它会现在做一个分析，分析了之后会分析出对应的产品跟技术架构。文档 啊，这个呢也是在我们的这个文档里面啊，编辑里面，文档里，首先他会去设计这样一个小文档，然后呢文档在这个文档内容确定没有问题的情况下呢，我们就可以后续进行第二次开发，也就是我们要确认开发，确认开发之后呢，他才会帮我们去创建这样的前端项目， 并且完成对应的这个前台项目。那这里出来个注意一个问题，就是他这里生成文件可能不说失败，你这个时候让他再自动自己做一个调试。嗯，他第一次第一次生成这一版呢，会存在一个问题，就是他会啊，因为你 生成的前端页面的话太简单，之后呢他可能就是生成一个单页面内容内容，但是我们需要去完善，我们 t s 需要他让你去生成一个完整的 h 网站，所以说我们可以看到我们展示的这个 啊，全能项目的话，其实是一个完整 hm 的， 这个是需要调试的，或者是你第一次写提示的时候，就让他去生成这完整的前端网站，这样的话他会根据你当前的一张的 vga 页面去扩展成一个完整的 hm 网站。所以最后呢扩展出来就是我们刚才这个这个展示效果。然后我们 生成完整之后呢，是可以去进行部署的，那其实部署的时候呢，就对应的他就会去让我们去做一个飞哥吗瘦脸，这个时候需要去使用到我们的啊 get 它的账号，然后进行部署生成部署，部署之后就对应的在这个 啊 work resume 里面就会有一个虚拟域，虚拟域网站我们可以直接访问我们章节部署的内容，这就是我们通过 flag 嘛，然后同时呢我们在生成完成之后呢，因为我们在开发完成之后呢，希望它去做一个沉淀，就是把对应我们这个项目开发过程中的经验呢，做成一个 两个比较高高价值的 skill。 这样的话在后续我们的移动端开发或者是 react 项目开发的时候呢，会附用这样的 skill 的 话，就可以让它去基于项目来去 沉淀这些 skill。 这 skill 的 这些规则啊或者是提示的话，都是不需要我们去学，而让 ai 去帮我们去生成完成。当我们对于它生成完成内容的话，也可以去理解理解之后呢，去定义出自己的一个 skills， 那 方便于后续的自己创建 skill， 更符合项目的开发。 那这个呢就是我们今天分享的关于这个啊，通过这个 solo 模式呢，使用这个 m c p 啊 m c p 再加上 skills 去完成一个啊前端的啊飞格玛设计稿，转转前端项目的一个开发的过程，谢谢大家。

hi， 欢迎回来，那么在开始本节之前呢，请你先下载本节的相应的资料。这一节的内容呢， 我比起上一节呢做了一些小的改进，我修改了里面的其中一些组建的内容，主要是这里的 circle property， 我 把这里的固定的文字替换成了 slot， 并且在 app view 中呢添加了这样一些 slot。 所以呢，这一节的代码和上一节我们所使用的这个应用的代码呢， 稍微有那么一点出入，要么你手动自己改一下，也就是把 circle property 这个地方的 slot 改出来，并且把这个地方呢稍微改一下，改成 circle size， 还有 circle rotate。 要么呢，你就直接下载本节的课程资料就可以了。那么我们这一节要做的呢，就是完成 我们目前没有覆盖的最后一个组建 circle property 这样一个组建的测试。那么这个组建的测试呢，其实和之前差不多啊，同样，我们先完成这里的渲染测试，渲染测试的我们要测试这里的 input 元素，这里的 label 元素，然后呢是交互测试。交互测试的话呢，因为我们这里只有一个交互，就是这里的 input 输入框，和之前的 checkbox 还有 select 一 样，我们都是要测试这样一个 input 里面它的值在随着用户交互之后，它的值发生的变化是否在我们的预期之内。那接下来你可以尝试一下去完成我们的渲染测试，或者再进一步尝试一下完成我们的交互测试。 当然这里的话呢，可能会有一一两点比较麻烦的地方，各位呢，可以尝试着去解决一下，当然解决不了也没关系啊，重点呢是要你自己有这样一个探索的过程。那么接下来呢，我就带各位看一下该如何解决 这个组建的测试。那么同样的，我们需要先创建相应的测试文件， circle property test t s 我 们导入相应的这样一些东西， itv 还有 itue 写上 script。 首先呢，是我们测试的这样一个文件名，然后呢是第一个组，第一个组呢，就负责我们的 random test， 对 吧？我们写上第一个测试， it should random the input correctly。 然后呢，我们需要在每次测试之前都重复运行我们的渲染逻辑，那这个地方的渲染的部分呢，就和之前稍微有一点不一样了，我们来看一下 before each， 然后下面使用我们的 random， 对 吧？ random 写上我们的 circle property， 那 这个地方呢，我们的 circle property 呢，它需要接收这个 slot， 那 这个 slot 我 们该怎么传进去呢？啊，这是一个问题啊，虽然看起来它好像没有报错，这样渲染出来也是可以的，但是呢，我们接下来如果没有这样一个传入的 slot 的 话呢，待会儿 我们去查询这个 label 标签的时候，我们该寄予怎样的标准来查询呢？我们之前查询 label 标签都是通过 label 标签里面的文本值，但这里的文本值呢，变成了 slot， 那 这里我们该怎么查找呢？所以呢，这里的 slot 我 们是必须要传进去的，那么这个地方呢，稍微麻烦一点， 我们就算来到 testing library 找到它里面的 view 这个部分，这里呢，关于渲染的内容的话呢，其实它什么都没有额外的介绍，可以看到 render 后面它也没有告诉我们该怎样去 传入相应的这样一些需要额外传入的东西，比如这样一个组建，我们该怎样传入它的 prompt， 在 测试的时候以及该怎样传入它的 slots， 但是呢，哎，各位还记得吗？我们之前有说过啊， view 官方其实有提供一个工具叫做 view test tutorials， 而我们这个 testing library view 它是基于这样一个官方测试工具的， 那么是不是意味着官方测试工具中所对应的这样一些写法，我们也可以在 testing library 中去用呢？我们可以来尝试一下。打开来到 view test youtube， 来到它的官网，我们来看一下它的文档，在下面找到 getting started， 我 们来到它的 渲染的部分，那么在 view 官方库有也就是这个叫做 view test utos 的 这个地方呢，它所对应的渲染的这个函数呢叫做 mount， 就是 挂载，然后可以看到它的挂载方式呢，和我们之前的这个做法其实是一样的，我们之前的 random 也是传入要渲染或者说挂载的这样一个组建，那么它这里也是一样，但是呢， 后面它多传入了一个对象，这个对象后面呢就是它可以传入的这样一些东西，可以看到这里它可以传入 prompts， 对 吧？那可以传入 prompts 是 不是还可以传入 slot 呢？我们来搜索一下 slot， 这里没有，那我们在这里全区搜索一下 slot， 这里的版本是不是有点不对劲啊？ 哦，这里是 v 一 的版本哈，它官网给的这个地址不太对，我们来到最新版最新的这个官方文档中，我们来 getting started， 下面我们在这里呢搜索这个 slots， 找到这里的 slots， 来看一下这里的写法。好，这里它给了一个简单的例子，它要测试的组建呢叫做 component view， 然后这个组建呢，使用了很多的 slots， 那 么在测试这样一个带有 slot 的 组建的时候呢，可以看到它的做法就是往这个 mount 函数，也就是渲染这个组建的函数中间的后面的这个对象中传入这样一个叫做 slots 的 东西，而这个 slots 呢，可以根据我们这个叉 叉槽的 name 进行传递，也可以传入这个默认叉槽对应的这个值，因为我们的 view 中的这个 slot 叉槽它可以有多种，对吧？那我们这里使用的是默认的叉槽，所以呢，我们选传入这个 default 就 可以了，那是不是意味着我们的 random 也可以这么写？为了验证这个猜想呢，我们直直接看一下这个 random 函数的源码，那么可以看到它抽象出来的这个函数 random 它会接收两个参数，第一个参数是 test component， 这个我们是没什么意义的。第二个呢是参数是 options， 我 们来看一下这个 option 参数，它的类型是 random options， 那 么刚好就可以看到 random option 这个参数下面它所对应的属性有 props 啊，这个可以理解，每个组键 很多组间都会有它的 props， 那 么这里还有一个叫做 slot， 那 么这里呢，我们基本上可以发现它的结构和我们的 view test youtube 的 结构是差不多的，那我们可以参照一下这里的写法， slots， 然后这里我们写上 default， 然后这里传入的文本内容呢，我们就写成 circle property， 希望是没有问题的。接下来的话呢，我们首先要对我们的 input 元素进行查询，然后进行搜索，然后进行测试。那这个地方呢，并不涉及到我们 slot， 所以呢，我们暂时不用操心。那这个地方有个问题， 我们这里要进行测试的组建它里面的这个 input 的 标签类型是 number， 和我们之前的 check box 还有 combo box 都不一样。那么它所对应的 rule 到底是什么呢？难道是 number 吗？那很明显没有，也没有这个 input， 对 吧？所以呢，我们要去 m d n 文档找一下它的 rule 角色。我们搜索 input element， 来到 m d n 文档，在右边找到 technical summary， 那么可以看到它所对应的这个角色呢，其实就取决于它的这样一个 type 属性。那我们这里的 type 属性呢？是 number 对 吧？啊，就在这里啊，它的 type 属性为 number， 那 么对应的它的角色就是 spin button， 我 们写上 spin button， 获取我们的 input。 然后呢，我们写上断言 expect input to be in the document。 此时测试呢，应该是没问题的。好，此时可以看到我们这个 circle property 这样一个文件，它的测试覆盖率就瞬间多了百分之五十啊，因为我们测试好了其中一个部分，然后第二个部分呢，就是测试我们的 label， 我 们来复制这个 it issued the label with correct text。 我 们要根据我们的这个文本内容进行查询，所以呢，这里应该是 get by text， 那 么这里的文本内容是什么呢？难道我们要手动写这里的 circle property 吗？而这里呢，我个人的推荐写法是在和渲染相关的这样一些测试中呢，我们单独写上当前这样一个测试它所对应的这个文本内容，那么我们这里的文本内容呢，我写成这个 slot text， 我 写成这个 component test， 这里的内容随便写，我只是做个演示。然后呢，我个人的想法呢，是在这里呢，对我们的组建再进行一次渲染，然后渲染的过程中呢，我们再把这里的 slot 再给它传进去，所以呢，我们复制这里的写法来到这里粘贴，然后把这个的 default 替换成我们的 slot text。 那 么下面查找的部分呢，自然就是我们的 slot text， 获得的元素就是我们的 label 存音箱，下面也是 label， 此时我们的测试就完成了，我们来看一下我们测试的结果，应该是没有报错的，对吧，看一下，没有报错，但是呢，其实各位如果在这里使用 screen 第一 bug， 你 会发现一个神奇的现象，我们之前有学过这个部分，对吧？大家会发现，在我们这当前这样一个测试 label 标签的这个测试环境中呢，它重复的渲染了两次这样 一些标签属性啊，我们可以在 vtest 的 ui 中看到更详细的，更明确的这样一些内容啊，应该是在 circle property 这个地方是吧？来看 console 啊，可以看到控制台中打印的部分呢，其实可以发现我们将这个 label 标签渲染了两次啊，这是为什么呢？这是因为我们自己在这个 before each 中，我们编辑了这个渲染的逻辑，所以呢，在下面这个 it 这样一个测试运行之前呢， 他自己就会先进行一次渲染，但这次渲染我很明显我们是用不上的，因为我们的渲染呢，要渲染我们针对性的这样一个擦槽的文字，对吧？那么这个地方虽然对我们的测试没影响，但是呢归是会影响我们 这个测试环境的独立性的。你可以尝试着使用我们的 clean up 进行手动的清理啊，也就是我们之前所学到的这个 clean up， 它是来自 testing library 中间的一个可以调用的函数。这样写好之后看一下我们，我还没有导入呢， 按下 tab 它就导入了。此时呢，再来到这个 console 中，可以看到它就只渲染了一次，因为我们把这个 before 一 直中渲染好的这个组件呢，我手动的给它清理了一下啊，这样的话呢，就不会产生什么冲突了。 当然就当前这个测试而言，其实我们清理或者不清理都是没有任何影响的。那么最简单的渲染测试完成了啊，这其实并不是本节的重点啊，本节的重点呢，其实还是在于我们的 交互测试。我们首先来看一下我们这个组建运行 dev， 我 们来看一下我们这个组建，我们这个组建呢，其实就是下面的这个 circle size， 还有 circle rotate 这两个 input 的 输入框。那我们要测试的就是 模拟用户输入对应的内容，然后呢判断这个输入框中的内容呢，和用户输入的内容是否一致啊？就这么简单，那么我们要模拟的重点就是该怎样模拟用户输入这样一个内容呢？那这里呢，我们需要回到 testing library， 在 它左边找到我们的 user interaction， 也就是所有和用户交互有关的地方。那这里我们可以看到有一个部分叫做 keyboard， 它的作用呢，就是 the keyboard a api allows to simulate interactions with the keyboard， 也就是所有模拟和用户 键盘操作相关的这样一些交互呢，都可以通过 keyboard 进行模拟，看起来好像满足我们的要求，对吧？但其实上呢，还有一个操作 在 utility a p s 这里呢，我们之前有用过里面的 select options， 那 么这里还有一个操作叫做 type type 操作呢，其实也可以满足我们的要求，只不过呢，它这里专门提到了 you should say keyboard， if you want to just simulate pressing buttons on the keyboard。 如果你只是想模拟在键盘上 输入，在键盘上按下按钮的这样一些操作的话呢，那么他推荐我们使用 keyboard， 而不是使用这里的 type。 所以呢，我们这里还是最好使用 keyboard 来模拟我们的用户输入，因为用户输入肯定是用键盘，对吧？他不可能用什么奇奇奇怪怪的方式，像我们开发的时候用什么 查找元素，然后直接修改里面的 content text， 这种操作用户肯定不会这样做，对吧？那么 keyboard 的 操作呢，其实很简单，它往里面传入的参数呢，都是字母串，只是呢，有些字母串经过转移之后，比如这里，我们可以通过这样的方式呢，模拟用户按下 shift 的 这样一个操作，那么 具体的很多模拟的部分呢，这下面都有相应的说明，如果你感兴趣的话，可以去简单看一下，那么这里我们要模拟的很简单，就是输入相应的这个数字，对吧？好，其实输入数字，比如输入三十，其实就是按一下三，再按一下零，对吧？那我对应的用户输入呢，其实就是传入 这个字母串，三十就可以了，因为可以看到它能够把对应的字母串呢拆解成单个的字母进行输入，就像它这里所说的，它输入了 f， 但实际上它模拟的操作就是输入 f， o， o 这三个字母。 ok， 那 我们接下来接下来来尝试一下这样一个 keyboard 的 操作。来到第二个组别， 我们新建一个 describe， 还是一样， user interaction， it should display the correct number in the input， after user input， 或者说 after user type， 那 么首先还是一样，我们要查找我们的 input 的 元素，对吧？ get by rule， 那 么它的角色是 spin button， 获取我们的 input， 然后用户就要进行输入了，对吧？ 那我们首先要获取我们的这样一个用户对象，来自我们的 uzi event 调用我们刚才看到的这个 keyboard， 那 么传入的内容呢，就是我们要输入的这个数字，那么这个数字呢？我抽象一下， input number 我 写成三十，然后呢，这里一定要注意啊，我们的 keyboard 里面传入的不能是数字，它只能传入字母串，所以呢，这个 input number 我 们要转换一下 input number two string， 然后这个 keyboard 操作和之前的 click 都是一样的，它是一个异步的操作， 所以呢，我们要加上 await， 整个函数要变成异步函数，那目前看来好像没什么问题了，对吧？那我们接下来使用断言，期望我们的 input 元素，它拥有相应的值，那么这个值就是我们 写进去的 input number， 那 这里呢，我们就要用这个 input number 这样一个数字来进行判断了，而不是它的字幕串形式。我们来看一下 vtest 哦，我还没运行，行吗？我运行一下测试， 哎，此时可以发现，我们的测试呢，啊，竟然失败了。在这个地方，我们的测试失败了，看一下这个测试的报告 report， 这个测试报告呢，很明显，它告诉我们 expected the element to have value 啊，我们预期的这样一个元素，它所拥有的这个 值应该是三十，但是接收到的值呢，是为 non， 这个就非常的神奇，为什么会为 non 呢？这里呢，还有一个部分，就是我们当前这个 circle property， 它其实还会接收这个 叫做 property 的 这样一个 model， 我 们其实缺失了这样一个 model， 或者说缺失了这样一个 props。 所以呢，这个这样一个 circle property， 它渲染出来的，它所对应的这个 input 元素中间的值呢，也是没有定义的啊。这个地方呢，其实我们 还缺少了一点，我们还需要加上这个 props， 这个 props 叫做 property， 它是一个数字，我给它写上零， 这样给他的值出手化之后呢，哎，此时呢，可以看到，他告诉我们，刚才接收到的值还是为零，现在就变成零了，那很明显，我们输入的值呢，并没有修改我们音符的元素中间的值，我们的修改是无效的， 也就是说这里模拟用户操作的这样一个 keyboard， 他 是无效的，这是为什么呢？那这里呢，我们要看一下我们用户使用这样一个组建时的场景，我们先取消我们的测试，回看一下我们整个项目， 我们用户的使用场景呢？我们以刚才的这样一个测试代码的角度来看一下，如果我们让用户来模拟我们这样一个使用场景的话，会是怎样？ 我们第一个操作是查找这样一个元素，也就是这样一个 input 的 元素，那查找这个动作在用户看来该怎么做呢？好像就是拿鼠标晃一晃，或者或者拿眼睛看一下啊，明确这个元素在这里， 这个 input 的 输入框在这个地方，然后呢我们就直接让用户输入了这个三十这样一个值，其实就是按一下三和十，对吧？ 比如我这里啊，我找到了这样一个 input 的 输入框，然后呢我输入三十，哎，发现什么问题没有？我们这里的值其实并没有被修改，为什么呢？正常我们的用户应该是点一下再往里面输入值，对吧？那很明显我们这里插了一个点一下的这个操作，这里相信大家就找到问题所在了吧，所以呢，我们这里还需要 让用户点一下我们要输入值的这样一个元素才行，也就是使用 click。 此时呢，我们再看一下我们的测试，此时所有的测试呢，都运行成功了啊，这里的报错呢就消失了，我们再重新运行一下， 然后来到我们的 coverage， 那 此时呢，我们的 s r c components 里面所有的组建它的测试覆盖率都是百分之百，这里的 circle property 就 没有没被覆盖的这样一些测试的部分非常简单，对吧？只是呢，这里的 s r c 里面跟目录下这两个文件，它提示我没有被测试覆盖到，但这个地方很明显 我们不需要去测试它当然看起来很烦，是吧？啊，为了解决这个问题呢，很简单，我们完全可以在我们的 vita 配置文件中，在这个 coverage 的 include 这个配置下面， 我们只包含 s r c components 下面的这些文件测试覆盖就可以了。此时我们刷新 再次来到 coverage 这里的话呢，我们所有的部分呢，它就显示测试覆盖完全了啊。再回到我们的终端这里呢，也会显示百分之百，所有的文件都是百分之百的测试覆盖，这又治好了强迫症了。那么到此呢，我们就完成了整个项目所有 组建的测试啊。今天这个组建呢，稍微比较麻烦，因为我们需要传入 props， 需要传入 slot 啊，尤其是这个 slot， 它和 view 组建的这个 slot 的 这个联系比较紧密，需要你去看一下 view 官方对这个 slot 叉槽它的处理方式啊。这里刚才我们翻了一下 view 的 官方测试工具它的写法，还翻了一下它的源码，对吧，才解决了这个问题。好，所以呢，这方面的文档是比较缺失的，如果你感兴趣的话，可以给 testing library 提交一些 pr， 帮助他们去解决这个文档缺失的部分。这一节比较重要的一下，在进行测试的时候，千万不要以 开发的角度去理解用户的操作，我们应该以用户的角度来进行测试，来理解我们用户交互的逻辑。比如刚才这个地方，我们想当然的就以为我们查询了这个元素之后，然后模拟用户输入内容，那么就应该是输入在这个元素中的。 但实际上呢，我们的用户应该是先点击这个元素再输入的，但我们之前的这个工程开发的习惯就是直接选择元素，然后修改里面的值，但是呢，用户是没有选择元素这样一个操作的，他只会点击元素， 拖拽元素，或者是把鼠标放在某一个地方点一下，他是没有所谓的选择元素这样一个操作的。所以呢，各位一定要完成这样一个思维上的转变，当然我知道这个很难，很多人其实都做不到这一点，所以导致在测试的时候呢，会有发生很多的疏漏， 这是很正常的事情。那么以上就是本期视频的所有内容，希望你能关注或定义我的频道，感谢你的观看，我们下期视频再见！

hi， 欢迎回来，那么这一节呢，我们继续完成 select color 这个组建的测试部分，那么我们之前只做了一些简单的测试，接下来我们要完成交互部分的比较麻烦的部分，那就是验证我们在模拟用户选择一个选项之后呢，整个这个 select 元素它的值是否变成了我们期望的样子，我们来试一下，还是回到我们的测试文件 select color， 我 们把上面这个这样一个组给它收起来。那我们接下来要做的呢，其实和上一节的差不多， 同样是先点击我们的 select， 然后呢选择其中的其中一个选项，最后呢是判断整个这个 select 元素它的值，对吧？那么 这里问题就来了，我们是要一直用 userclick， 然后点击这个 select， 再通过 screen 查找 我们想要的这样一个 option， 最后呢，再通过 userclick 点击这样一个 option 元素，然后再判断我们的 select 它是否符合我们的要求嘛？啊？中间呢需要点击两次啊？当然，从我们的 模拟用户的角度来说呢，确实好像就是需要点两次，对吧？先把我们的这个列表点开，然后选择选项，看起来确实是要点两次的，但是呢， 在我们的 testing library 中呢，它其实提供了一个工具，专门针对我们的 select 进行呃，这样一个选项切换的这样一个功能。好，我们可以来到 testing library， 我 们搜索 select 这里呢，在 user interaction 这里呢，它的 utility apis 这个地方呢，可以找到 select options， 那 么它刚好就是针对我们的 select 这样一个元素标签的，所以呢，我们直接使用这里的 select option 就 可以了，那么可以看到它的用法其实很简单，就在这里，第一个参数呢，就是要进行切换的这样一个 select 元素。然后第二个参数呢，就是选择 要切换的这样一个 value 值，或者说它中间的文本。那这里呢，可以是数值啊，也可以是单个值啊，因为这里它给了例子， 它给了这个 select 的 例子呢，它可以选择多个选项，但我们呢，只能选择一个，对吧？我们先给它复制过来。来到这里，我先把这个测试的名字改一下， it should display 我 们首先呢，先一个 选项一个选项来进行测试，我们把这里的选项呢给它截个图，不然待会有多少选项我们都不记得了的话。首先呢，这里 it should display text black with 然后是 after user click the black option。 我 们期望的是用户在点击这样一个文本为 black 的 选项之后呢，我们 对应的 select 元素，它中间的 value 值就变为了 text black， 对 吧？那么我们接下来把点击并且切换这个部分呢，我给它替换成我们刚才学到的 select option。 第一个参数 设置成我们的 select。 第二个参数呢，我们先来看一下我们的方法定义，函数定义告诉我们，第二个参数，它的类型其实可以为很多种， 还可以是一个自复串，也可以是一个 h t 幺元素，或者是 h t 幺元素的数组，或者是一个自复串数组。这里呢很明显就对应着单选和多选的两种情况，那么我们这里只能单选，所以呢，我们要传入的这个文本值就只能是 text black 啊，就对应着我们这样一个 option， 它的这个 value。 然后第第一个参数应该是 select， 这样的话我们就成功切换了。切换完成之后呢，我们就期望这里的 select 元素，它的 value 值为 text black， 这里呢，我就叫 to have value text black 啊。这样写好之后呢，大家能够发现这里的 text black 其实我们重复了很多次啊，那我干脆把它单独的抽象出来，我写一个单独的变量，我就叫 option value， 再把这里的 text black 全部换为 option value， ok， 那 此时我们运行测试看一下结果，测试成功。这里呢，我们的 should display black after you click the black option。 这个测试呢，就成功通过了，但这里我们只是运行了其中一个测试啊，那接下来的测试该怎么做呢？接下来的测试难道我们要一一重复吗？比如这这里的三个选项，那我们难道要一一重复 三个测试嘛？比如把这个地方哈复制一份，然后改掉这里的 black， 把这个 black 改为 orange， 把这里的 option value 改为 text orange， 然后再重复一次嘛？啊，这样显然是比较麻烦的，有没有什么方法能够让我们只改这样一些 啊，会产生变动的地方，但是整个测试逻辑能够保持不变。这个东西看起来好像有点像书组， 大家发现没有，我们只需要保证数组中的每一个元素发生变化，但是呢，处理每个数组中的这样一个逻辑不变就可以了，对吧？有点像我们学习过的 for each。 那 这里呢，很明显，我们的 v test 应该有考虑过这样一个方案。我们来 我们的 v test 官方文档看一下，其实在我们的 api test api reference 在 右边的 test 这个地方，大家能够发现 test 它其实不只是或者说我们的 it， 它其实不只是提供一个简单的测试，这么简单啊，它在后面呢还可以加上一些后缀，那么这些后缀呢，其中一个 可以解决我们今天的问题的就是 test each， 那 么 test each 呢，就有点类似我们 javascript 数组中的 for each 这样一个处理函数，那我们看一下它的用法， 它的用法呢很简单，首先 testeach 它中间要接受的参数就是这样一个数组中的每一个元素呢，你可以自定义 啊，可以是像它这样定义成数组，也可以定义成这样一个对象。重点是呢，该怎样利用这样一个 testeach 中间的这样一些数组元素呢？那这个地方呢，我们就以这样一个例子为例啊，我们来看一下该怎么解决。还有刚才那个组建选项的这样一个 截图啊，我也给它截过来，那我们接下来把这个地方给它注湿，复制一份注湿掉，作为参考，我们接下来对它进行 it each 的 这样一个改造。那么首先它接受的参数是一个数据库中的每一个对象呢？这里我定义成一个 object， 定义成一个对象，然后对象中的属性，这里我设置成 option value， 就是 刚才我们定义的这个 option value。 首先呢，第一个它的值是空字不串，就在这里啊，空字不串，第二个对象它的值呢应该是 text black， 第三个呢就是 text orange。 那 么接下来问题就来了，我们光是把这样三个值给它写上去了，但是呢，这个 option value， 首先我们要怎样来影响我们每一个测试它的名字呢？就这个地方，我们的测试名字肯定要跟着变，对吧？那么可以看到 vtest 它给的例子呢，就是在测定义测试名字的时候呢，如果我们要取 这个便利数字中元素的属性的话，我们可以在属性名称前面加上一个美元符，就可以表示我们在引用这样一个对象中间的属性，那么我们这里要引用的是 option value， 所以呢，我们把这个 black 我 给它设置成美元符， option value 啊，就这么简单。好，这样我们的变量名，我们的这个测试名称跟着我们的测试中间的值发生了变化，但是呢，这里啊，这里的这个 option value 有 一个比较尴尬的点，我们的 option value 其中一个值它是为空字不传，那么这里呢，我们干脆在这个每一个对象的 中间呢，我再加一个属性作为说明，我加上一个 label 属性啊，这里各位随意啊啊，第一个 label 属性呢，设置成 white， 第二个 label 属性呢，就设置成 black， 第三个呢，就是 orange， 其实就是我们这个 option 选项 这样一个元素，它的中间的文本值，对吧？这是一一对应的。然后这里呢，我们就不用 option value 了，这里我就利用刚才我写好的 label 就 可以了，这里我们的测试名完成了。那么接下来我们该怎样在测试过程中去引用这样一些 变化的值呢？这里很明显我们要引用的是 option value 这样一个值，对吧？那这里呢，我们的 vtest 它给出的建议是，它给出的这个用法呢，是直接在我们第二个参数这样一个匿名函数的参数列表中， 使用解构的语法直接解构得出同名的这样一些变量，就像它这样，它利用到的是这一个对象中的三个属性，所以呢，直接用解构的方式写出三个属性变量就可以，也就是在这个地方，那我们之前一直没有在我们的测试函数中 它的参数列表做任何文章，是吧？那这里呢，我们要进行这样一个啊，便利测试的话，我们就必须要利用这里的参数列表，我们进行结构，然后呢得到我们的 option value， 那 么接下来这个 option value 我 就可以删掉了。好，这里都是设计好的。 ok， 那 我们看一下测试的结果呢，我们来到 vtest 啊，此时呢，可以惊奇地发现，我们刚才只是针对一个测试的用力，把它改成了 it each， 对 吧？但是呢，下面就多出来了三个，只是其中有一点点区别的，这样三个不同的啊，测试用力啊， 可以看到其中一个测试叫做 should display white， 下面就是 should display black 和 should display orange， 很 明显，这里的这个值呢，就是和我们这里的 label 相关的啊，非常的简单。然后呢，测试的值的话呢，其实就是这里的 option value， 这样的话呢，我们就成功解决了测试逻辑相同，但是呢，相应的测试值不同的这样一个尴尬的情况，我们通过 eight h 可以 非常轻松的解决这样一个问题 啊，那么有了 eight h 之后呢，后续如果我们还会遇到这样的情况，也就是下拉栏或者说其他的一些列表，它中间 只有值不一样，但是测试逻辑完全相同的情况下呢，我们都通通可以使用我们的 it h 来进行解决，我们只需要在 it h 它的数组中呢追加相应的元素就可以了， 中间的测试逻辑呢，都不需要我们再重复的去编写。那么以上就是本期视频的所有内容，希望你能关注或订阅我的频道，感谢你的观看，我们下期视频再见！

嗨，欢迎回来，那么我们的测试做到现在呢，大家会不会发现一个问题呢？就是虽然我们现在的组建呢比较少，只有这三个是吧，但如果我们的组建多起来，我们每次呢都要看我们 测试文件写的哪些，我们的组建有哪些，然后一一对应，来查看我们哪些对应的组建没有测试到，以及当我们的组建特别复杂，可能有几十甚至上百行的时候呢，到底哪个部分有测试，哪个部分没测试，我们又该怎么评判呢？那难道要我们 人工一个一个去叫对嘛？显然是不太现实的，有没有这样一种工具，能够自动的生成相应的测试报告，让我们快速的进行对照呢？啊？那么 vtest 作为一个新型工具，自然是有这个功能的，我们来到 vtest 的， 它的文档，在左边的 get 下面找到 coverage。 啊，之前我们用到了 vtest ui 对 吧？那么 coverage 呢，就是提供这样一个测试报告功能的，那么首先呢，需要在我们的 这个配置文件中添加 coverage 这样一个配置项，并且在 provider， 也就是提供商工具提供者这个配置项这个部分它有两个选项，默认的话是 v 八，然后你也可以选择 assemble。 把这个配置好之后呢，我们要在下面安装相应的依赖，那我们先使用 v 八，来到我们的 v 配置文件，在 test 这一栏添加我们的 provide。 然后呢，我们为什么一定要使用 v 八，而不是使用 assemble 呢？为什么官方推荐我们使用 v 八呢？ 呃， v 八的话呢，顾名思义啊，它是需要依赖我们的 v 八引擎的下面呢，是它的一些优点，还有一些缺点，看起来好像， 嗯，一般般是吧，但实际上呢，它的另一个选择 is tembo 是 二零一二年开始就已经存在了，是一个酒精考验的这样一个测试覆盖率 报告工具。那比起 v 八呢，其实有这么多的一些缺点，并且建于我们当前的这样一些项目的，都是前端项目，所以呢，肯定是会用到 v 八隐形的。所以呢， v 八的缺点呢，其实对我们来说几乎是不可见的。因此呢，我也和官方一样啊，更推荐各位使用 v 八作为我们的这 个测试覆盖率的供应商或者说提供者。那这样配置还不够，我们还要在下面的 carriage setup 配置这个地方呢，在我们的配置文件中，把这个 carriage 功能呢给它起用起来，这样呢，才能够开启我们的测试 覆盖报告。当然呢，你也可以选择在我们的这个 vtest 的 运行脚本中添加这样一个 flag， 但我的建议呢，是添加在我们的配置文件中，同样的，来到 coverage 下面添加 enable。 那 这样的话呢，我们接下来还不够啊，按照上面的说法，我们是需要安装这样一个 v 八相关的依赖的。那这里呢，我不推荐各位手动安装这个依赖啊，我更推荐各位呢，在运行这样一个测试，并且尝试进行代码测试覆盖报告的时候呢，让他来指引我们安装啊，什么意思呢？此时呢，可以看到我的测试呢，刚才 明明是正常的，现在它就自动地报错了是吧？此时我在运行，再回到我们的终端，最终端，它就直接问我们是否要安装这样一个 carriage v eight 这样一个依赖，所以呢，我们直接按照它的 指引安装就可以了，我输入 y， 这样的话我们就不用手动输入了，对吧？此时呢，我们再次运行我们的测试脚本，那此时我们的 vtest ui 中呢，就会多一个按钮，在这里之前呢只有三个按钮，如果你有注意到的话，这里呢多了一个按钮叫做 coverage。 我 点过来之后呢，它就能够展示我们当前这样一个 测试文件中的覆盖率，但是好像只检测到了 select， color， 还有 toggle purple 这两个组件，对吧？但实际上呢，我们还有一个组件叫做 circle property， 为什么它没有检测到这个组件的测试覆盖率报告呢？啊？这是因为呢，我们还缺失一个配置啊。在我们的 carriage setup 下面，我们还可以设定我们整个测试报告它的覆盖范围和它排除的范围，也就是这样一个 include 这样一个配置。那么可以看到官方文档中给的这样一个配置的视例呢，是参照 react 来做的，它后面的这个后缀呢是 ts， 还有 tsx， 那 么 tsx 呢，一般就是 react 或者说 solid 这样一个文件，这样一个 前端框架组建的后缀，对吧？那我们把这个 t s x 呢改为 view 就 可以了。我们复制这样一个 include 来到 coverage， 我 们把这个 t s x 改为 view， 此时呢，再回到我们的 v t s u i， 我 重新运行，我按一下 r， 它就能重新运行了。 好，我再手动刷新一下，此时再回到我们的 coverage， 此时呢，它就能够自动地对我们 s r c 中所有的这样一些 t s 和 view 为拓展名的这样一些文件呢，进行测试覆盖率的这样一些检测。那么此时我们可以点击这里的 s r c components， 查看 components 下面这三个组建的测试覆盖率报告，可以看到我们之前所做测试的 select color 还有 tiger purple， 它的覆盖率都是百分之百。后面呢，还可以以这个 函数分支还有代码行数为基础呢，进行覆盖率的检测。而上面我们的 circle property 这样一个组建呢，我们没有针对它写任何的测试，所以呢，它的覆盖率自然就是百分之零，对吧，这个非常的合理，甚至呢，如果组建特别多，我们还可以在上面手动的输入组建的名字进行筛选。 这里有一个 filter， 看起来我们好像已经完成了这个代码测试测试覆盖报告的这样一个功能，但实际上呢，目前这个功能看起来好像只能和我们当前的项目进行绑定。我们想要获知我们当前这样一个项目的代码测试覆盖报告的话呢，我们必须要首先下载 我们这样一个项目，并且运行 vtest 才可以。那有没有什么办法能够把我们的测试覆盖报告分享出去呢？毕竟报告肯定就是用来 要做汇报的，光在我们自己的电脑上运行肯定是不够的，那，那我该怎样分享呢？啊？其实我们这里回到我们的 项目中，可以看到我们运行这样一个测试，我们添加了 coverage 这样一个配置项之后呢，首先我们的终端中它出现了这样一个测试报告的这样一个汇总情况，我们在终端中也可以查看，当然肯定是不如我们的 vtest ui 这么方便的。第二个呢，就是我们的 vtest ui 中出现的这样一个代码测试覆盖报告率的这样一个 页面呢，其实是基于它自动生成的这里一个 carriage 文件夹下面的这样一些 html 文件， js 文件还有 css 文件组合起来得到的这样一个小网页的，我们可以把整个这个 carriage 文件夹给它分享 出去就可以了，比如这里的 index html， 我 打开这个文件之后呢，我通过 live server 打开这样一个单独的 html 文件，可以看到上面的端口和我们的 vtest 的 端口是完全不同，也就是说在我们这个地方呢，只需要参照 coverage 中生成的这样一些简单的前端页面，我们就可以把我们的测试报告分享出去了， 功能和刚才是一模一样的，你就把它当成一个网页来用就行了。甚至呢，我们点进这样一个组件之后，我们能看到组件当中有哪些部分没有被测试覆盖到他这里都会给上相应的标识，包括 测试了多少次，这里也是有相应的标识的，比如这个地方，他告诉我 text color， 他 重复进行了六次测试，是吧？但这个评判的标准呢，可能不是那么准确啊，但是呢，只要大家保证我们测试的覆盖率能够达到百分之百或者 相近就可以了。那么有了这个工具呢，我们就不再需要手动的去一个一个对照，我们有哪些组建没有完成测试，或者说你组建的哪些部分没有完成测试了，我们就可以根据这样一个功能给我们提供的测试覆盖率报告呢？这样方便的补充我们当前 项目中缺失的这样一些代码测试。那么以上就是本期视频的所有内容，希望你能关注或点我的频道，感谢你的观看，我们下期视频再见！

嗨，欢迎回来，那么这一节呢，我们来继续做我们之前的这个组建测试，那么之前的测试中呢，我们只测试了这样一个组建中这样一个 check box， 还有这个 label 标签是否存在，以及这个 check box 它最开始的状态是否是 not to be checked 这样一个状态，对吧？但实际上呢，这个组建呢，它是可以进行交互的，所以呢，我们其实还缺少一个用户交互的这样一个测试，也就是测试一下用户在点击这样一个 check box 之后呢，它的状态是否会变化的这样一个测试， 那这个测试该怎么做呢？哎，回到我们的 testing library， 来到它的文档，在左边呢，可以找到这样一个部分，叫做 user interaction， 我 们来看一下它的介绍，那么这样一个库呢，其实就是用来模拟我们的用户交互的，就在这里啊， testing library that simulates user interactions。 那 么这里需要注意啊，它模拟交互的行为呢，不是直接 发送这样一些动请求来实现的，或者说它不是让我们一个一个的来发送动请求来模拟我们的用户行为的。其实在 testing library 它内置的一个库 叫做 fire event 中呢，它其实就是通过这样一些底层的浏览器 api 来实现的，但这种方式呢，其实并不好，它的问题就是我们一个用户的行为，它通常呢要用我们的浏览器 api 来模仿的话，其实会比较麻烦，就比如 我们刚才的这样一个操作，用户的话只需要把鼠标移在上面，然后点击就可以了。但是呢，我们如果用一些浏览器 api 的 话，我们首先 选择元素，然后呢焦点集中，然后呢再触发点击事件，然后鼠标再移开，这些全都需要借助相应的一些 event 事件来完成，这一点的话呢是比较麻烦的，但我们的 user event 这个库呢，它就可以直接通过相应的函数来实现 用户操作的模拟，而不是我们去编辑相应的一些疑问的事件来实现。好。我们来看它的安装，它的名字呢很简单，同样是 testing library 前缀，后面呢是 user events， 我 们来安装一下， 然后呢我们来看一下它的用法，这里的 setup 用法呢其实特别简单，首先是导入回到我们的测试文件导入， 然后呢在使用它之前呢，我们需要通过这里的 user event 调用 set up 方法，然后呢返回得到一个 user 对 象， 通过这个 user 对 象，我们就可以调用其中的各种各样的函数方法来进行模拟了，比如这里的 keyboard 就是 用来模拟我们用户的键盘输入的，再比如这里的 click 就是 用来模拟我们用户的点击操作的， 我们接下来呢参照他的这个用法来试一下，我们直接复制，复制之后呢，这里我们要对我们的这个测试呢进行简单的分组，那么可以看到之前我们所编写的这两个测试呢，他们都是关于组建渲染相关的一些测试的，对吧？所以呢我们干脆给他 单独分一个组，那么我们分组该用什么呢啊？很明显该用 describe， describe 就是 用来分组的，所以呢我们可以在 describe 里面呢再写一个 describe 进行分组，这里呢我们就叫 random test， ok， 然后呢我们再写另一个 describe， 这里呢我们就写上 user interaction， 在 里面呢再写上我们的测试，这里我写一个，我要打一个 i， 然后呢让它自动呢帮我生成相应的模板， it should be checked after user click。 那 么同样的这个测试，我们首先要通过我们的 screen 获取我们的这个 check box， 对 吧？ check box 获取我们的这样一个 check box 元素， 然后呢，我们需要通过上面的 user event 调用 set up 进行设置，以及用返回的这样一个 user 对 象进行点击，就是我们刚才复制的这样一段代码。 我们在上面呢，需要注意这里的 user click， 它是一个 promise 函数，所以呢需要使用 await， 整个这个函数呢必须是一个异步的函数。那么中间我们选择这样一个元素呢，就是 check box。 最后我们写上言 checkbox to be checked， 我 们来测试看一下效果，那此时呢，我们的测试就通过了，可以看呢我们的测试呢，经过简单的再次分组之后呢，我们的测试整体就变得比较的清晰了，那么这里最顶层的测试呢，它还是显示 type purple random test 啊，我把这个后缀给它去掉， 就只保留我们的文件名，那这样的话我们整个测试的层级就更加的清晰了，最外层是我们这个组建的名字，然后呢第一个组别是用来测试我们的 这个渲染的，第二个组别是用来测试我们的用户交互的，这样的话我们的测试呢就非常清晰了，我们 刚写好的这个测试呢，也非常完美的通过了，那么相信呢，通过这一节简单的例子，大家就快速了解了怎样模拟我们的用户交互来进行测试，之后呢，我们会学习更多的一些用户交互来满足各种各样的测试需求。那么以上就是本期视频的所所有内容，希望你能关注或订阅我的频道，感谢你的观看，我们下期视频再见！

兄弟们最近接了个企业项目给客户做检测，实验室的智能 lims 管理系统、客户管理、合同管理、财务管理、 代办事项等等功能列表拉了一屏。今天我来通过这个实际的项目，一步一步教大家如何使用 ai 设计工具，帮助我们生成所有功能界面的 ui 设计与前端工程代码。 这里我们使用 pixel ai 来帮我们完成所有的 ui 设计。首先我们来看如何生成设计稿，输入我们的需求功能描述，为了保证 ai 生成的效果符合你的预期，这里输入的越详细越好，这里可以选择使用的模型 技术站。前端框架 ui 风格生成，移动端或者是 pc 端的 ui， 点击发送开始生成。这里 ai 会帮我们总结需求的情况，设计考量的因素，采取的专业风格等。这里我们稍作等待，很快就帮我们生成了可交互的 ui 设计稿。 我们点击全屏预览一下整体效果，整体的设计效果还是不错的，也基本符合企业级系统的 ui 风格。 客户管理、合同管理等子页面功能也都帮我们生成了一版功能列表，操作按钮等效果也都符合需求。我们把生成的设计稿转成可编辑文件，可以拖拽到我们需要修改的地方，点击进行调整。重点来了，切换到代码模式， 这里就是所有设计稿对应的代码目录和代码文件。直接点击下载，下载所有前端代码到本地，通过 vs code 等开发工具可以直接运行调试。接下来我们继续首先执行 npm install 来安装一下前端依赖包， 再运行 npm run dev 来打开前端调试服务，直接通过浏览器打开前端页面。首先是打开了我们的登录界面，输入用户名密码进入主页面，各个子功能也都生成的非常完整，直接点击就可以进行交互，这样完善的前端功能页面就生成好了。 也可以直接使用 m c p 功能将设计稿数据传送至 ai 编程工具 curl code 中，智能化生成前端代码，实现设计到代码的转变。回顾一下，按照上面的步骤重复进行功能设计， 就可以一步一步构建一个完整的企业级系统。前端功能从需求到设计稿到可用前端代码， ai 极大地提高了我们的生产力。

兄弟们，推荐一个前端 ui 的 skill ui ux pro max， 这个在 github 上已经有超过二十四 k 的 star 了，正好我想做一个管理浏览器多账号的桌面软件，我就用这个试了下水啊，对我来说还是挺惊艳的。 先打开这个 github 仓库，为什么要用豆包打开呢？因为在这里可以直接问豆包，我想用 tree 技术架构是 tree 啊，要让 ai 知道。 好，豆包回答我了。第一步，安装 c l i 工具，我们复制命令，在命令行窗口粘贴好了，安装成功了。注意，这里的前提是要安装好 n p m。 然后第二步，执行技能安装好，复制过来。 技能安装好以后可以看到啊，在点翠的目录下生成了相关的技能。好，我们继续啊，豆包告诉我们，我们只需要用自然语言描述就可以了。那好，那我跟 ai 说，为我的 python 六加 qml 的 应用设计一个主页，要求界面是暗黑风格，有科技感，高端大气上档次。 请参考我给你的设计图，记得把图片复制给 ai。 ok， ai 已经开始做了，差不多一分多钟的样子， ai 就 完成了，看一下效果怎么样， 是不是挺是那么回事的，不过 icon 都是色块，看不出感觉。让 ai 再优化一下，这里有个小技巧啊，这个优化任务应该比较简单，所以我们用国内版的 ai 打开，用免费的 ai 来修改就好了啊。 告诉 ai， 如果 icon 没有图片的话，请用第一个字母。 ok， ai 开始工作了，也差不多是一分钟左右啊，又好了，我们看一下效果怎么样，是不是很惊艳，可以看到鼠标一上去还有交互的特效。 ok， 今天就分享到这，后面我会继续围绕这个项目分享实战干货，有兴趣的兄弟可以关注一下，拜拜了。

今天学这个一句话，简单三步，生成 ui 界面，不仅可以直接转成可编辑的设计稿，还可以导出前端代码。第一步，在首页点击 ai 生成设计稿，直接大白话，告诉他你的需求即可。比如让他设计一套音乐 app 的 ui 界面， 这里可以按需选择代码模型，包含了大厂的组建，供你选择，支持自定义主题颜色，记得选择 app 端或者网页端。等待两分钟， pixel ai 就 会直接生成一套高保真的 ui 界面设计，还可以继续让它生成登录界面的设计，能够看到它直接延续了整个设计风格，而且效果还不错。 点击代码也可以直接复制。第二步， u i 界面转成设计稿，接着点击右上角，还可以直接转成可编辑的设计稿，每一个按钮卡片、文字都是可编辑的适量元素，你可以随便修改文案颜色、字体大小， 还可以对组件添加效果，比如这个迷你播放组件，可以添加一个背景模糊效果，修改一下参数，让效果更佳。 第三步，下载代码交给开发，点击这里进入开发模式，点击 d to c， 选择一个代码设计稿，一键变成可交付的工程代码，可以直接下载代码包，这对产品设计开发来说真的很友好，你学会了吗？下期见！

设计一次，但是前端也要拉着一起陪葬，最近发现一个特别好用的工具，直接就是能把前端一锅端了，根本就不用再求前端。 给大家看看 stitch， 它是 google 开发的，它这个应用呢，是专门为 ui 设计师量身定制的 ai 界面生成工具，并且它这里生成出来的画面，它可以查看代码，我把它的这个代码复制一下，然后直接把它粘到 file 里面， 它就直接生成了这么个界面。设计，这是我的原型图，这是 ai 给我出的图，而且它都是可以选择编辑的，是原文件。就是这么一个工具，把设计变成了代码，代码即设计，以后再也不用看前端的脸色吃饭了，大家赶紧去试试吧！

hi， 欢迎回来，那么经过我之前的演示呢，相信各位不免会有疑问啊，为什么我们要在我们的 vtest 的 使用过程中使用这样一个 来自 testing library 的 这样一个第三方工具呢？为什么一定要用它呢？有没有什么其他官方推荐的选择？或者说一定要学习这个第三方工具的理由是什么呢？这里我们来到 view 的 官方文档来查看相应的答案。我们来直接搜索一下 test， 来到它的 testing， 在 testing 这个部分的 view 的 文档，它会详细的讲解关于测试的一些比较详细的内容，当然主要是 针对 view 前端应用的测试的方面，它会比较详细的给你讲解测试的类型。为什么要做测试，但是呢，它在这个过程中其实并没有着重的去介绍具体的测试 该用什么工具啊，它只是简单的讲了一下关于这个 unit test， 也就是单元测试中，它只是简单列了两个工具，这里的 recommendation 单元测试的推荐工具，这里它第一个推荐的就是 vtest， 这是一个官方的工具，对吧？然后的话，另一个选项是 jest， 但是呢，我们现在还是使用 vtest 比较好，因为它和 vt 生态语结合更紧密，对吧？但除了这两个具体的工具之外呢，在 view 官方文档中，其实并没有详细的讲解具体该用哪样，该用哪些具体的工具库去实现相应的测试。也只是在这里呢给出了三个选项，第一个呢是一个叫做 view test youtube 的 一个库，然后呢是 sepress， 然后呢是我们使用的 testing library， 那 么看起来有三个选择，那为什么我们要用这个 testing library， 不 用前面两个其中其中的一个呢？这里呢， 我们先来做一个简单的试验，我们来新建一个带有官方自带框架的这样一个 view 项目。我们来到桌面，我还是用 create view 创建一个新项目 view test demo 还是一样啊，我们选择 type script， 选择 vtest。 回车回车回车。进入这个项目，我用 vsco 打开，那么当前这个项目中的 我们直接来到它的 s r c 下面，来到它的 components， 可以 看到它的 components 下面就有新建一个 tests 这样一个测试文件目录。我们看一下它创建的测试文件中用了什么东西。可以看到这里除了我们的 v test 中间引出的 describe， it expect 这些我们比较熟悉，对吧？这里的 it 的 话呢，其实就和 test 是 一样的，但是下面多了一个东西叫做 view test youtube 啊，这是个什么库呢啊？我们可以来到 package json 看一下，在这里 view test youtube， 我 们可以点过去看一下这个库它的 get up 链接。这时候呢，大家就会神奇地发现这个叫做 test youtube 的 这样一个工具库呢，它既然来自 viewjs 这样一个组织下面， 那说明呢，这个库应该是 view 官方给我们提供的用来测试 view 项目的一个工具，但是呢，为什么我不推荐它呢？为什么我不在最开始各位上手的时候就用这个官方的工具呢？大家看一下它上次更新的时间已经是一年前了，对吧？ 好，差不多一年半了吧，它都已经没有再更新了，并且它的 star 数量也不是很多，说明它其实并不是非常的流行，就算它是官方的工具，那不用这个官方工具，那又为什么要用上我们之前展示的这个 testing library 呢？它又有怎样的魔力呢？我们来到 testing library 的 这样一个官网，那么首先一个比较重要的点就是这个叫做 testing library 的 这样一个工具库呢，它不是和任何一个前端绑定的，并且呢，在它的 view 的 这个版本中呢，可以看到这样一段话， view testing library built on top of dawn testing library by adding apis for working with view component 啊，最重要的是这里这一句话， it is built on top of view test uts the official testing library for view 啊，它是基于官方所建立的这个叫做 view test uts 的 这个库的基础上 来构建的，它是直接兼容了官方构建的这个测试库的，所以呢，我们直接使用它，其实也相当于变相的使用了官方给我们提供的这个测试工具，并且呢，可以看到这样一个 测试工具，它的 star 数量也是一千一百，而官方提供的这个工具呢，也是一千一百，但是呢， 它作为在官方工具上进行构建的工具的话呢，它的这个项目版本是和官方基本同步的，可以看到它们都是停留在了去年，所以呢，其实用它和用官方工具的话并没有什么两样，只是呢，语法上有些不同，但是因为这个工具它可以用于多个 前端框架，所以呢，我更推荐各位学习它，这样的话之后，如果你想要将你的这样一些测试的经验给它平移到其他的前端框架，比如你在 这个 view 项目中，通过 testing library 这个库编辑的一些测试，你想要迁移到 react 项目中，那你只需要更改一下项目依赖更改一下这个导入的包名。可以看到啊，导入的这个包名只需要从 testing library view 改为 testing library react 就 可以了，其实并没有什么两样。 所以呢，综合所有的这样一些因素，我现在更推荐各位直接直接去学习使用这个叫做 testing library 的 工具。当然了，后续我们会学习其他的一些更简单的工具库来替代它。只是呢，现在 啊，大多数人还是基于这个虚拟动物进行测试的情况下呢，各位还是需要学习这样一些比较通用的测试工具，来兼容之前的这样一些老版本的测试方式。那么以上就是本期视频的所有内容，希望你能关注或定义我的频道，感谢你的观看，我们下期视频再见！

嗨，欢迎回来，之前的所有学习中呢，我们一直都没有系统性的学习过，到底测试该怎样分类，以及我们到底要做怎样的测试，对吧？ 今天呢，我们就以理论的方式呢，简单带各位介绍一下关于测试的分类，还有我们大致的一个测试的方向，这样也让大家心里有一个底。那么这里呢，我们直接以 vivo 官方关于测试的部分呢，说实话，写的挺好的， 隔壁 react 写的好多了，隔壁 react 完全是不管大家的这个死活的。那么关于测试呢， view， 这里其实说的也很简短，后面呢，我会以另一篇 blog 为补充，带大家看一下具体的内容。那么这里的话呢，它大致把测试分为了这样三个类别，第一个是 unit， 即所谓的单元测试，这也是很多人一直听过的一个词，单元测试呢，其实不管是前端还是后端，它都是存在的，只是呢，在前端中，单元测试很多时候都被弱化了， 位，它有另一个东西为替代，就这里的 component， 大家可以把它理解成组建测试。大家通常意义上理解的前端开发中最小的单位，其实不是所谓的类或者说函数，而是我们的 component 的 组建，也就是一个点 view 文件，大家通常都把它作为最小单位来理解。然后呢，就是 所谓的 e to e， 也就是所谓的 n to n， 很多地方也把它叫做 e， e to e， 也就是所谓的端到端测试。那么它们三个的区别呢？其实很简单，所谓的 unit， 也就是单元测试，其实就是以 某一个东西为最小单元，可能是一个函数，可能是一个类，甚至也可以是我们的组件，所以呢，这个单元测试它到底以以什么东西为准，就决定了我们 整个测试它的编遣方向。所以呢，这个是有很多争议的，如果你只只写个后端应用的话呢，你会觉得单元测试就只针对一个函数，或者说一个 controller 进行测试就可以了，但是在前段中呢，是比较复杂的，所以呢，这里第二点显现出来了，我们的组建测试，也就是以组建为单位，测试它的 这样一个渲染是否正常，它的交互是否正常，这其实是我们之前一直在做的事情，我们在测试它的 render 渲染部分，还有 interact， 也就是 和用户交互的部分啊，这是我们一直在做的测试，并且这个地方强调了一下， these tests import more code than unit tests 啊，这个地方往往写的代码呢，是比起我们的 这个单元测试是要更多的啊。这里就不得不提到很多人会推崇的一个简单的图标，它叫做 test pyramid， 也就是所谓的测试金字塔，就是这样一个图。在大多数人的认知中呢，所谓的测试一般都是分为单元测试，集成测试，还有最上层的这个端到端的测试啊，但实际上呢，在有前端中，一般来说没有中间这个所谓的集成测试的部分，因为 中间的这个集成测试的部分呢，一般都被我们的组建测试给它替代掉了，甚至呢，很多单元测试呢，都给它囊括到了我们的组建测试中呢。其实很多时候，我们 与其说它是单人测试，不如说它是组建测试，而最后这个 end to end， 也就是所谓端端端端端测试，其实就是遵循我们用户的这样一个使用的具体流程来实现 这样一个测试。那么端端端测试呢，也是最最少的，因为它涉及到流程比较多，所以呢，测试编辑和维护都是比较麻烦的。那具体下面的介这些介绍的话呢，大家可以选择性的看一下，主要的话呢，还是这里他推荐的 工具，我看应该是在这里啊， recommendation 这个地方，在这里的单元测试下面它推荐的工具呢，有两个啊，第一个呢，很明显就是他们 view 生态官方所推荐的这样一个 vtest 啊，这也是我们在学习使用的工具。第二个呢才是 test， 虽然现在 test 还是用的人偏多，但是我相信未来肯定是属于 vtest 的， 因为 vtest 能够和我们的 vt 进行深度的集成，依靠 vt 生态，相信它其实用不了多久就能够超越 test， 并且 vtest 现在的功能呢，也越发强大，其实在功能的丰富层面上， 是要远超我们的 test 的， 只是这个迁移成本可能有点高。具体这里的内容呢，我就不细讲，因为我们其实暂时还涉及不到最上层的这样一个 e to e test， 所以呢，暂时没有讲的必要。那么接下来呢，我就以一个 vlog 为例子啊，带各位看一下关于测试的更深入的内容。这是多个作者一起写的它们 的这篇 blog 的 话呢，是基于多个企业进行调研之后编写的一份关于前端测试的一篇 blog， 我 觉得非常有价值，虽然是为了推广他们的产品，但是呢，中间关于 单元测试，组建测试，基层测试，还有端大端测试的内容呢，都非常值得各位去仔细阅读啊。这里我只挑几个我觉得比较重要的部分呢，给各位简单讲解一下。那么首先呢，就是 测试它具体在前端开发的过程中应该做什么，或者说我们在前端的应用中测试的东西到底是什么啊？就在这个地方， what to test？ 好， 我们具体测试的是什么？这里它分为了五个部分，第一个部分，逻辑 及我们对应的前端应用的这样一个逻辑，它是否正确。然后呢是 random and behavior， 渲染与行为，对吧？也就是我们组建它是否能够成功渲染，以及 它和我们的用户交互是否正常，其实我们目前就停留在上面这两，当然我们目前做的还是第二层，也就是 random and behavior， 我 们现在主要还是集中在组建的测渲染测试，还有它的用户交互，行为测试上。那么逻辑测试的话呢，类似于我们的单元测试， 逻辑测试的话，一般来说就是用来测试我们的各种各样的一些小函数，小的一些工具类的，但我们目前还没有给各位展示过，对吧？那么后面呢，我们结合一些更复杂的场景呢，我们 会涉及到相应的内容。然后第三个是 accessibility， 也就是无障碍，那么这一点呢，对于前端来说是非常重要的，只不过呢，很多很多的前端开发，它其实都会忽略这一点，尤其是在中国，中国其实 基本上不怎么注重无障碍这一块，别说无障碍了，尤其很多前端开发，他对他的整个用户体验都不是很好，更别说去兼顾你的这个无障碍。那这里所谓的无障碍呢，就是我们的前端应用对于屏幕阅读器是否足够的友好， 或者说对于只用键盘来进行浏览的这个场景下呢，是否足够友好，这一点呢，我们依然没有涉及到，对吧？那么说实话，无障碍的这样一个 测试的话，它也是比较难的，因为大多数人其实没有没有通过屏幕阅读器，或者说只用键盘的方式来浏览过网页，所以呢，很多测试人员很难想象该以怎样的方式来测试我们前端的这样一些方面，这也是一个比较难的点。第四个呢就是 appearance， 即所谓的这样一个组建，它看起来的样子，这个呢也是比较抽象的。最后呢就是 user flows， user flow 其实就是刚才我们的测试金字塔上面的最上一层 e to e test， 它用来表示的就是模拟我们整个用户它的一个实际的交互行为的这样一个测试。那么很明显这样五种测试的内容呢，它是 由浅及深，由简单到复杂的，所以它给了一个更为复杂的一个模型。最下面的是 static， 也就是一些简单的代码测试，比如代码的类型检查，代码的规则检查啊，这些呢我们用一些第三方工具，比如我们用 type script， 我 们用一些 yes link， 或者是 bio me， 或者是 ex c， 相应的这样些 linter 和 format 都都能够帮我们解决相应的问题。 然后呢是单元测试 unit test， 然后再往上的话，可以看到它其实分为了很多种，这里有一点我觉得非常值得各位关注，就是这里的 component， component 就是 组建的意思，那么 component 的 测试包含了什么呢？就这里的 random， 还有 user behavior， 也就是这里的第二步渲染和我们的用户交互测试，那么可以看到它在这里的占比呢，甚至超过了我们的 unit test 单元测试，对吧？那么为什么组建的测试会 远超于单元测试呢？而不是像我们刚才看的那个金字塔一样，明明应该单元测试最多的啊，这也就是前端测试和我们 呃传统的这个测试三金字塔之间的一个冲突的地方，或者说不一样的地方。前端测试中呢，很多时候，我们的最小单元其实应该是前端的组建，尤其是在我们都以组建为单位进行前端开发的这样一个大背景下，大多数的前端测试呢，都会注重以组建为这样一个 unit 进 测试。并不是说单元测试它不重要了，而是单元的这样一个最小单位，从一个模糊的 unit 这样一个单词，变为了我们 在前端场景中更具体的 component 组建这样一个单词啊。所谓的 component test， 你 也可以理解成另类的 unit test， 它也是一种单元测试，只是划分的这个单位不一样， 仅此而已啊，这是在前端中比较特殊的一点，但是这里呢，很明显可以看到它没有强调所谓的集成测试，也就是这里的 integration test 啊，这是为什么呢？啊？这其实是因为在我们所谓的组建测试中呢，很多时候它其实就包含了一些集成测试啊，很多时候呢，就包含了这个父子组建的一些 联动起来的测试，或者说包含了一些在一个比较长的流程中，比如我们之前实现过的，在一个组建中实现用户点击选择，然后验证的这样一个 比较长的测试流程啊，这个也其实也算是一种集成测试，它们都包含在了我们的 组建测试中，也就是这里的 component， 所以呢，这个 component 看起来非常的大，它包含了大部分单元测试的中间的一些内容，它也包含了一部分集成测试中间的内容。然后呢，在这篇 vlog 的 第三点， unit， 也就是所谓的单元测试这个地方呢啊，它详细讲了一些和单元测试相关的东西，是吧， 它在这里的这样观点呢，其实就和上面这个图片完成了吻合啊，重点就是这里这一句话， however， unit tests are used less frequently in front end development because a majority of our code is intended for the web browser。 即所谓的传统的单元测试，其实在前端开发场景中呢，它是比较 少见的，因为在前端开发的场景中呢，我们的代码它基本上都是要在浏览器中运行的，所以呢，大多数都是所谓的 mostly integration， 大 多数都是所谓的集成测试啊， 所以呢，传统意义上的那种单元测试，就是以某个单个函数，单个工具类为单元的。这种单元测试的话呢，在前端中其实比较少见，更多见的还是在 强调过的以组建为单位的测试，所以呢，单元测试的概念呢？各位在前端中就不要过度的去纠结它了，我们在前端中应该着重了解的应该是这里的 component， 我 们接下来看一下 component 它讲了什么，那么在 component test， 也就是组建测试这里呢，它给了一个明确的定义 啊，这个定义的话呢，未来的话呢，有可能这个观点会发生一些转变，所以呢，各位不必去纠结，它给的定义就是 component tests bridge， the gap between unit and n to n test， 它是单元测试和端到端测试的这样一个桥梁，也就是说呢，我们的组建测试，它其实 既包含了一些单元测试的特性，它也包含了一些端到端测试，或者说所谓的集成测试的这样一些特性。所以如果大家真的要去细分这样一个所谓的前端测试，它具体属于哪一类的话呢？ 如果用传统的这样一个这样一个测试金字塔去划分它，是没办法把它划分到某一个 层次中的，那只能说它位于中间这一块啊，从上到下它都有设计。所以呢，我之前的课程中呢，也一直没给各位强调过我们编辑的这样一个测试的分类，因为如果用传统的分类来讲，其实是比较难讲清楚的，那么回到这张图本节的重点呢，其实我还是希望大家 记住这样一张图中比较重要的 component unit， 还有 n to n 这三个部分就可以了。大家只需要知道，在前端测试中呢，我们应该着重关注的是我们的 component 为单位的这样一些测试，而不是去纠结它到底是所谓的单元测试，还是所谓的机身测试，还是所谓的 端端测试啊？其实在一个所谓的组建测试中呢，它这三个东西都有可能设计，或者是它可以同时实现这三个东西。那么希望这一节呢，可以让大家了解到在前端中的 测试的分类应该是怎样的，我们所谓的组建测试，它到底意味着什么？那么以上就是本期视频的所有内容，希望你能关注或定义我的频道，感谢你的观看，我们下期视频再见！

就在今天， astonovic 放出了他们的最强模型 cloud office 四点六这个最强的头衔，它只保住了二十七分钟，半个小时不到， openai 直接在线狙击发布了 gpt 五点三 codex。 这里放一张今天特别火的图，美国的 ai 大 战 vs 中国的 ai 大 战，大家怎么看？熟悉我的朋友都知道我的 ai 大 战 vs 中国的 ai 大 战，大家怎么看？熟悉我的朋友都知道，我的模型评测风格一般，不去看一些奔驰实测， 两个模型同一个 problem， 正面硬钢，剧透一下哈，结果挺意外的，一个功能做全了，但代码有坑，一个代码漂亮，但他前端漏了功能，到底两个模型哪个写代码更能打？看完这个视频你心里就有数了。 好，我们下面来快速过一下模型树懒部分 off。 四点六这边三大亮点，第一个， 它的一个上下文翻了五倍，到了一百万 token， 但目前只能按 api 付费的用户才能去体验。第二个 agent teams， 多代理协助，不是以前那种只代理模式，是真正的团队多个 agent 并行干活，互相沟通，质疑，不通过这个负责人去中转。第三个的话，它整个的一个输出 token 啊，翻倍了，由原来的六十四 k 到现在一百二十八 k， 可以 执行一个更长的一个任务，不中断。好，我们来看一下 gbt 五点三 ko deck 这边在第一项这一块， terminal bridge mark 这个参数呢，它是比 office 四点五要强接近十二个百分点，并且 这个速度相较于它的上一代模型快了百分之二十五左右，我的一个体感非常的明显，特别快。第二个的话是它的一个 首个参与构建自身的一个模型，也就是说他用早期的版本来 diabag 自己的个训练管理部署，然后针对评估 ai 帮自己 diabag， 想想就挺科幻的是不是？第三个的话是以前扣贷干活你只能等着，现在你可以随时介入，随时去调方向，不用先停止了。 那真实项目这一块的话，我给他准备了两个项目，第一个让他去做一个跨项目的一个迁移认证体系，也就是说我有一个纹身图的一个 agent， 我 要让他去参考另外一个项目，把那部分啊，谷歌邮箱登录、 github 邮箱登录 认证全部给他摘过来，这个考验他对另外一个项目的探索能力、架构适配能力。但第二个项目的话，我之前做了一期视频，是讲 skill 的 加载原理的，那并且我也做了一个开源项目，把它放出来了，那个时候是一个终端交互的一个性质，现在我把它做成一个外部 y。 第一个是 cloud 四点六完成的一个落地页，大家觉得怎么样？就一般般吧。那它在登录这一块的话， github 谷歌邮箱注册全部搞定了，没有任何的问题，我们也可以试一下，点击 可以看到它能登录成功邮箱也是对的，那整体这一块的话，它是整个完成度还 ok 的。 我们来看一下 gbt 五点三 codex 表现怎么样。 首先落地说实话不太行，比较简陋，大家看它的那个集成登录的情况，只实现了 get up 后端的代码，谷歌那边它也完成了，但是它没有在前端上写一个按钮。整体这一块的话，我会把票投给 cloud off 四点六 单看功能这一块哈，但是后面还有坑，待会我再慢慢讲。好，下面我们来看另外一个项目，就是给一个 skills agent 去加一个 外部 ui 嘛，因为之前是终端，我们来看一下，也就说我有这样的一个项目啊，这个项目是去使用当前一点零去构建了一个 skills agent， 演示了这个三层加载的一个原理嘛， 那主要的一些特性的话，就是有一些流势输出，然后托肯的响应，显示工具的名称，执行的过程，展示三层 skills 的 一个加载过程。原来的话是通过终端 ui 去交互的嘛，现在我希望他给我们做成一个外部版本，我们直接来看结果， 这个是 cloud 的 off 四点六完成的，这个 ui 太简陋了。 ok 来给了一个这个平台的文章，让他去做 思考，他会去做加载技能，然后去分析，再提取，再做其他的一些任务，看他能不能做到。 ok， 可以 看到他有调用的 skill 去加载这一个 skill， 然后他去执行那些命令，他发现这是命令有问题，他这个时候需要去安装相关的依赖， 那这个的话就是 gpt 五点三 codex 完成的，左边是他发现了我安装了哪些 skills， 并且右边你可以开多个聊天框去聊天，我在提示词里面其实有让他去要去实现对应的一些指令，那 gpt 五点三这一边的话是完成的非常好的。好，我们来试一下， 可以看到这边它加载了就是新闻提取器，这个时候它会去执行霸性，跟那边一样，因为一些依赖问题，这个先忽略它，总之就展示这一个加载的过程嘛， 很明显 gpt 五点三 codex 完成这个版本会比 off 四点六会好很多，我感觉不管从 ui 上交互上， 这一轮我会给他投票。好，我们来看一下完整的一个对比结果。第一个项目就是给这个 agent 加上一个用户认证体系嘛，主要是 email， 谷歌认证 get up， 然后从另外一个项目迁移过来。我们来看一下评分情况， 对话人数大家都用了第一轮，那功能完整程度的话， off 四点六这边要完整一些，所以给了他九点五分。 那 gpt 五点三这边因为它漏了嘛，所以说它的评分要低一些，在 ui 上的话也是这边会好一些。在代码架构上这个就有有的说了，在代码架构上的话， off 四点六这一边就是快，但它整体的实现其实有有一些漏洞， 那 gpt 五点三扣带这边它就像一个更有经验的工程师一样，然后整体的代码架构，工程规范都很完美， 为什么会得到这一个评分呢？给大家解释一下这个评分怎么来的。他们两个模型把代码写完， get commit 提交完了之后， 我用了他们两个最顶尖的模型去 review 代码，先让 off 四点六去 review 啊，两个人写的，再让 gpt 五点三 code 是 两个人写的，大家得到的结果都一样，就是 gpt 五点三 code 写的代码要好， 只不过在功能实现上它漏了，以及在落地页上它的实线会没有 off 四点六那么好看。但是代码这一块的话， gdp 五点三扣袋子这边肯定是要厉害一点的。 那整体总结一下的话，在代码架构上扣袋子要领先一些，它全链路的用户隔离、迁移、脚本测试覆盖都写到了。但实际功能体验上的话， off 是 因为它三种登录都可用， 然后 codex 它这边缺少了一个谷歌的，我不知道它为什么会缺少的。哈，那 ui 设计上也是 office 更优。那第二个想法，就我们刚刚看到的，我们把这个 skills agent 的 一个终端 ui 变成一个 web ui 嘛，那这块的话， gpt 五点三就明显领先了，不管是在 ui 上还是整体的代码实现上， 都要领先于这个 off 四点六。所以说我觉得整个这一次的发布来看的话， off 四点六它的代码提升并不是特别明显，反而这个 gpt 五点三 codex 相较于 gpt 五点二 codex， 我 认为它们提升了蛮多的。因为这几天我也一直在用 gpt 五点二 codex， 以前是速度有点慢，现在是速度又快，质量又高，我觉得未来 g p t 五点三 codex 大家会用的特别多，不像以往一样，大家可能都用 cloud code 的， 现在的话多了一个选择，并且它更便宜。我做这一期测试，我把这个 off 四点六这个模型的 整个五个小时的窗口全部用完了，但是这个我只花了二十道订阅了，它还没用完，一直可用，一直可用，很爽，速度又快，那为什么不选择一一个便宜，质量又高的呢？所以这一轮总结来看的话，就是 codex 整个代码实现明显领先，功能实现也领先，整个 uiux 都领先，所以说我把票投给了 codex。 好，我们来一个总结，第一个项目去做跨项目的一个迁移认证，这轮 off 四点六渗出， 第二个把一个终端 ui 变成外部 ui， 这一个 gpt 五点三 codex 渗出。那整体平均来看的话， codex 是 要领先一些，因为它这一次提升真的非常明显，速度快，成本更友好，而且后续的话我会更加的去增加我整个 codex 的 一个使用频率。 ok， 这就是这一期视频的全部内容了，如果你觉得视频做的不错，可以给我一键三连，谢谢大家，拜拜。拜拜。

朋友们用 cloud skills 做出来的前端页面真的很好看，这是我花十分钟做了三个页面，第一个，写作工具。 第二个， ai 简历助手。 第三个， cloud skills 社区， 不用画设计稿，不用写一行代码。接下来告诉你我怎么用同一套 skills 做出不同风格的高质量前端页面。这个 skill 是 在两个神级 skill 的 基础上改造出来的。 第一个神级 skill 叫 flow and design， 它是 called 官方出品的 skill， 它的特点是没有 ai 位，创造力比较强。第二个 skill 叫 ui ux pro max， 它是 github 上的一个神级开源 skill， 它提供了一套规范的 ui 库，让你可以精准复刻某个产品的 ui 规范。 在这样的基础上，我改造出了这个 skill， 它同时具备设计的创造力，还能精准的贴合我要求的 ui 规范。我们先来看一下这个 skill 的 架构。首先有一个主控 skill， 它通过和我对话，理解我的需求，然后判断对应的设计场景，最后再确定调用的方案。 调用方案确定后，执行层的 skill 就 会开始工作。接下来我们看一下完整的工作流程。第一步， ai 会向用户了解设计需求。第二步，主控 skill 会基于需求判断设计场景和确定最终的设计路线。 如果用户想做一个风格独特的网站，但它的规范性没有要求，我们就走路线。一、纯创意的方式把这个网站做出来。 如果用户强调规范性，但他不太在意设计感，那我们就走路线。二，纯参考，但用 u i u x pro max 的 数据库找到一个案例，把它复刻出来。 如果用户既需要有风格，又需要有规范性，那我们就走路线三，先通过 u i u x pro max 提供参考的规范，然后 form and design， 再去主导整个设计语言，给出最终的规范。库数量有限，所以我做了一个 u i u x pro max 提取的 skill， 它的工作方式是输入一个 url， 它就调用 playwrite 进行页面的捕获，同时拿到网站的截图和 css 代码。 拿到代码的截图后，它就会开始进行分析，分析完成后会在 url 叉 pro max 数据库里面新增一条规范，然后把对应的参数全都填进去，这样我们就能快速复刻某个网站的设计规范。有了这套 skill 后，想做出好看有品味的前端页面真的太简单了。 今天的分享就到这里了，你还想用 close skill 帮你解决什么问题？欢迎在评论区跟我留言，我们下期继续。