1.2.2　单元测试概览

单元测试是对应用程序最小的部分（单元）运行测试的过程。通常，测试的单元是函数，但在Vue应用程序中，组件也是被测单元（稍后会详细介绍）。

还记得计算器应用程序吗？代码中应用程序使用一个sum函数对两个数字进行求和。

如果为了易于阅读，你又编辑了该函数，你需要测试该函数是否仍能正常工作。你可以运行一个端到端测试，但如果端到端测试失败，你无法知道问题是因sum函数还是因源代码中其他函数导致的。确定是否因sum函数而导致失败的唯一方法就是单独运行sum函数。单元测试可以完成此操作。

单元测试可以单独调用源代码中的函数并断言其行为是否正确（见例1.2）。这是一个简单的程序，导入sum函数，运行它，如果sum函数不返回2，则抛出错误。

例1.2　一个基本的单元测试

因为单元测试是针对一个独立的单元运行的，所以当一个写得好的单元测试失败时，它会成为一个闪烁的霓虹标志指向问题代码。

与端到端测试不同，单元测试运行速度很快，只需要几秒钟的运行时间，因此你可以在每次代码变更后都运行单元测试，从而快速得到变更是否破坏现有功能的反馈。

单元测试的一个好处是提供文档。如果新入项目的开发人员需要了解单元代码的行为，他们可以查看测试以确切地了解一个单元代码的行为方式。

我之前提及过flaky端到端测试，即使应用程序正常工作，测试仍经常失败。写得好的单元测试不会遇到这个问题。只要单元测试是确定的，运行一千次也都会通过。

至此，关于单元测试我只介绍了优点，但我并不想误导你，与端到端测试一样，单元测试也有其自身的问题。

单元测试的一个大问题是重构代码困难。人们不经常谈论这个问题，但我对这个问题却深有体会。

定义　重构是重写代码的过程，通常是为了提高代码质量，但这取决于谁在进行重构！

如果要将一个已具备单元测试的复杂功能拆分为两个单独的功能，需要在更改代码的同时更改相应的单元测试。这样重构就变得不那么吸引人了。我曾在一段时间里不愿意对代码结构进行变更，因为这样需要更多额外的工作来更新单元测试。但没有轻松的解决方案，想要长效地节省时间，单元测试就是额外需要考虑的事情。

单元测试的另一个问题是它们只针对应用程序的各个部分进行独立检查。它们可以测试汽车各个部件是否正常工作，但无法检查部件组装在一起后，发动机是否可以正常启动。这是单元测试无法解决的问题。它们可以确保单元代码的行为符合预期，但却无法保证各单元之间交互是否正常。这就是为什么需要用端到端测试补充单元测试的原因。

到此，我已经完成了对端到端测试和单元测试的概述。最后，我要向你讲授的测试类型是快照测试。