官方推荐的vitest方法
在vue3+typescript项目中，一般来说用vite做构建系统。做测试的话，目前官方推荐的是vitest。官方文档在
在vue3+typescript+vite5项目中，运行安装命令
npm install -D vitest就可以把vitest安装好。
在package.json中的script段增加一行
"test": "vitest run"在vite.config.ts文件中，加入首行
/// <reference types="vitest" />在plugins段增加一条
test: {
// include:['**/*.{test,spec}.?(c|m)[jt]s?(x)'],
globals: false,
environment: "jsdom",
},这是对vitest的配置项。因为我是用vue3开发网页，所以这里用的environment是jsdom
在项目目录的src目录创建一个test目录，在这个目录中写测试代码
按照vitest的约定，测试代码的命名规则是test_name.spec.ts或者test_name.test.ts，其中test_name由开发者自己定义，后面的spec.ts或者test.ts则是系统要求的。将来在调用时，可以在项目的根目录运行命令
npm test test_name就可以针对这个文件单独进行测试，而不必按照监控模式随时测试，也不必一次性把所有的测试用例全跑一遍，因为后面两种模式速度比较慢。
按照vitest的官方文档中的例子
// sum.test.js
import { expect, test } from 'vitest'
import { sum } from './sum'
for(let i:number=0;i<20;++i){
console.log([Math.random(), Math.randome()])
}
test('adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3)
})其中sum来自开发者自己开发的代码，通过test、expect、toBe就可以进行测试
实际上这个代码是按照从上到下的顺序执行的，也就是说，在test被调用之前，其实还可以做很多。比如说有这么一个函数，可以生成一系列散列点，而且是随机的，所以无法直接在test里通过expect和toBe来测试，但是可以在test之前，通过console.log()来输出，然后用其他工具——比如Excel——对这些输出数据进行处理——比如绘制散点图——来检查。
在一个vue3项目中，因为目录和代码组织的关系，必须要靠vite才能把不同目录的代码组织起来。以前js时代还勉强可以用node搞一搞，直接把一些调用函数的引用关系用相对目录写死，但是ts还需要编译，这种方法几乎不可行。直接简单的写一个ts文件，是不能通过npm直接调用这个ts文件来运行的。但是通过vitest就可以这样直接运行了。
一般来讲，这种方式我会用来测试执行复杂的关联比较多的函数。
直接用vite生成新项目来测试小组件
对于大型项目而言，单文件组件single file component缩写SFC是广泛使用的。
vitest提供了vue3组件测试的功能，但是经过实践检验，它仅用于测试组件是否出错，比如说语法错误之类，但是对于组件最终的呈现效果，是不会呈现的，所以有时候vitest测试vue3 component没出错，但是这并不意味着没有问题。
所以我一般还会单独测试小组件。方法就是用vite生成一个新的项目
npm create vite@latest随后按照提示选择vue3和typescript，这样就生成了一个新的最简单的项目。
在这个新生成的项目里，直接把新开发的component放进去，然后检查其呈现效果。
如果这个component需要一些额外的数据，可以通过上面章节vitest运行特定的程序来输出，再把输出结果直接复制粘贴到这个新项目的component里作为硬编码。反正只是临时性测试，硬编码就别在意了。
但是如果使用这种方法也无法检测出问题所在，尤其是怀疑到vue3本身的时候，就必须要使用更底层的方法来处理。
直接用vite生成新项目来测试typescript代码
vite一般是搭配一个框架来构建项目，这个框架一般是vue3或者react。但是其实vite可以构建一个不依赖于任何“框架”的typescript项目。在
npm create vite@latest之后按照提示选择Vanilla和typescript即可。这样vite就会创建一个纯粹的不基于任何框架的typescript项目。
如果怀疑代码涉及到vue3内部的一些机制导致代码出错，这个时候可以用这种方式构建一个完全不依赖vue3的项目，在这里测试这些“纯”代码。
那么为什么不直接不使用任何构建系统，用一个空的html和js来测试呢？
因为如果涉及到npm包，如果手动下载配置就会很麻烦，尤其是很难得到编辑器的高亮显示和跳转支持。另外如果开发者自己开发的代码中涉及到复杂的目录组织，涉及到import/export，直接用空的html来测试就会非常麻烦。
采用vite生成不依赖框架的项目，最适合这种情况。
