动机
我今年的目标是在 Github 上搞一个能获得 512 star 的项目，但我究竟要做一个什么项目，目前并没有什么好的想法。但在想法来临之前，我会先去分析现在流行的开源项目，看看它们究竟做了些什么，能够收获几千甚至上万个 star。
因此我将会写一系列的文章，每篇都会聚焦一个现在流行的开源项目，从一个产品的视角去分析它：
- 要解决什么问题，满足什么需求？
- 目标用户在哪里，以什么样的一句话卖点打动对方？
而最近我工作中有对现有项目增加单元测试的需要，所以就从如今十分火热的前端单元测试框架 Vitest 开始，让我们看看 Vitest 究竟依靠什么，让它能够在 jest 的火热程度下，还是能够脱颖而出。
Vitest 介绍
Vitest 是一个基于 Vite 实现的测试框架，它非常快。
从2021年12月4日，Anthony Fu 提交第一行代码起，截止到2023年2月10日的今天，Vitest 已经收获了接近8k个 star 了，而且仍然保持着惊人的增长趋势。
Vitest 要解决什么问题，满足什么需求？
一般性问题
毫无疑问 Vitest 作为单元测试框架，首先要解决的必然就是单元测试有关的一切一般性问题。这一点我们可以通过 Jest 框架的文档来了解，因为 Jest 作为先行者，创建了完美的 API，并推动了很多测试模式的发展，这些模式现在已经成为 Web 生态系统的标准，Vitest 的第一个工作就是实现 Jest 的所有功能。
- 无需配置。Jest 的目标是在大多数 JavaScript 项目中即装即用。
- 优秀接口。从
it到expect- Jest 将工具包整合在一处，文档齐全、不断维护。 - 快照。轻松编写持续追踪大型对象的测试，并在测试旁或代码内显示实时快照。
- 隔离的。并行进行测试，发挥每一丝算力。
- 安全快速。确保您的测试具有独一无二的全局状态，Jest 才能可靠地并行测试。为了缩短测试时间，Jest 会优先运行未通过的测试，并根据每个测试的时长调整测试顺序。
- 代码覆盖。无需其他操作，您仅需添加
--coverage参数来生成代码覆盖率报告。Jest 可以收集整个项目的覆盖信息，包括未测试的文件。 - Jest 使用自定义解析器来导入您测试中的依赖，让您轻松模拟测试范围外的对象。您可使用富模拟函数 来模拟导入，并借由简单易读的测试语法监视函数调用。
- 追根究底。当测试报错时，Jest 会提供丰富的上下文内容。
Vite 单元测试问题
除了单元测试的一般性问题，Vitest 作为一个从 Vite 核心团队头脑风暴中孵化出来的项目，它设计之初最主要的目的，就是为了解决在使用 Vite 来进行开发时，使用现有单元测试框架会存在的一些问题。
Vite 在开发环境使用 ESBuild 构建，生产环境使用 Rollup 构建，这导致 Vite 有自己独立的插件生态和独立的配置。当你选用 Jest 时，Jest 与 Vite 的构建方式并不一致，你需要为 Jest 进行单独的配置。而使用 Vitest 你就可以将开发、构建和测试环境的构建方式统一，并且共享相同的插件和 vite.config.js 。
这里所讲的就是 Vitest 除了 Jest 提供的功能之外另外要解决的问题，是 Vitest 项目创建的动机，也是其卖点。
目标用户在哪里，以什么样的一句话卖点打动对方？
由于 Vitest 在设计之初，就是为了解决在开发者使用 Vite 的场景下，进行单元测试存在的问题，Vite 用户自然也很容易转化为 Vitest 用户。在使用 Vite 作为构建工具的框架，比如 Vue 和 Svelte，使用它们的脚手架时，都会询问是否要使用 Vitest 作为单元测试工具，这就是背靠大树的好处！
Vitest 也从 Vite 中获益，让它能够拥有比 Jest 这个竞争对手更块的速度，使用 Vite 即时热模块重载（HMR）的默认监听模式，也让开发者的开发体验有飞跃的提升。如此极快、智能即时浏览模式成为了 Vitest 另外两大卖点。
我觉得 Vitest 做的非常明智的事情就是与 Jest API 保持了较高的兼容性，让使用 Jest 编写的单元测试能够非常容易地迁移到 Vitest 上，再加上它的卖点，让使用 Jest 的开发者有充足的动力尝试 Vitest。
总结
Vitest 的成功在于，当一个新的构建工具产生的时候，需要有一个新的单元测试框架，来匹配这个构建工具的插件生态、配置，能够让开发、构建和测试环境统一。而伴随着 Vite 的成功，Vitest 自然作为 Vite 默认的单元测试框架候选项也吸引了大量流量。
且也从 Vite 的构建速度和 HMR 中收益并作为卖点，与 Jest API 保持了较高的兼容性的 Vitest 也吸引着使用 Jest 的开发者前来使用。
