一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第10天，点击查看活动详情。
我们是否也应该为我们测试的类使用这些钩子？
在将这个指令设置为要测试的目标元素之后，你可能想知道是否还应该使用它们来替换我们正在积极寻找的类。让我们来看看第一个测试中的断言:
expect(wrapper.findAll('.active').length).toEqual(3)
我们是否应该对具有活动类的元素使用 v-test，并替换断言中的选择器。
单元测试就是一次测试一样东西。It 函数的第一个参数是一个字符串，我们用它从消费者的角度描述我们正在做的事情。
包装我们断言的测试显示呈现一个类活动等于 prop.grade 的星列表。这是消费者所期望的。当它们将一个数字传递给 grade 属性时，它们期望获得等量的活动星体或选定星体。然而，在我们组件的逻辑中，活动类正是我们用来定义这个特性的。我们根据一个特定的条件来分配它，这样我们就可以从视觉上区分活跃的恒星和其他恒星。这里，这个特定类的存在正是我们想要测试的。
因此，在决定是否应该使用已有的选择器或设置 v-test 指令时，问问自己: 我在测试什么，使用这个选择器对于业务逻辑透视图是否有意义？
它与功能测试或端到端测试有什么不同？
起初，对于单元测试组件来说，这可能看起来很奇怪。为什么要对 UI 和用户交互进行单元测试？这难道不是功能测试的目的吗？
在测试组件的公共 API (也就是从消费者的角度)和从用户的角度测试组件之间，有一个根本却微妙的区别。首先，让我们强调一些重要的东西: 我们测试的是定义良好的 JavaScript 函数，而不是一些 UI。
当你查看单文件组件时，很容易忘记将组件编译成 JavaScript 函数。我们没有测试底层的 Vue 机制，这个机制通过这个函数导致面向 ui 的副作用，比如在 DOM 中注入 HTML。这就是 Vue 自己的测试已经解决的问题。在我们的例子中，我们的组件与其他函数没有什么不同: 它接受输入并返回输出。这些原因和后果是我们正在测试的，没有别的。
令人困惑的是，我们的测试看起来有点不同于常规的单元测试:
expect(add(3)(4)).toEqual(7)
毫无疑问。数据的输入和输出是我们所关心的。对于组件，我们期望事物呈现为视觉效果。我们正在遍历一个虚拟 DOM，并测试节点是否存在。这也是使用 Selenium 或 Cypress.io 等工具进行功能测试或端到端测试时所要做的。那么这有什么不同呢？
你不需要混淆我们正在做什么来获取我们想要测试的数据和测试的实际目的。通过单元测试，我们测试孤立的行为。使用功能测试或端到端测试，我们测试场景。
单元测试确保程序的单元按预期的方式运行。它面向组件的消费者ーー在软件中使用组件的程序员。从用户的角度来看，功能测试可以确保功能或工作流的行为符合预期，即最终用户使用整个软件。
结论
我不会详述每个测试的细节，因为它们都有一个相似的结构。你可以在 GitHub 上找到完整的规范文件，我强烈建议你尝试自己实现它们。软件测试既是一门科学，也是一门艺术，希望可以帮助到你。
