告诉你单元测试应该如何做！

lsekfe

为什么我们会决定将单元测试作为测试的主要方法呢？在很大程度上，这是因为更高级别的测试一直被认为太难、太慢和不可靠。
　　如果参考传统的测试金字塔，您会发现它建议测试的最重要部分应该在底层的单元测试。原因是，更高层次的测试认为是更慢且更复杂的，因此您需要将精力集中在金字塔的底部，以获得高效且可维护的测试：
　　金字塔模型旨在传达好的测试方法应该涉及许多不同的层。专注于极端可能会导致测试太慢，或者无法为软件开发带来任何信心。也就是说，人们往往以为单元测试的投资回报率最高。
　　更高层次的测试尽管为软件开发带来更多的信心，但通常最终会变得缓慢、难以维护或过于广泛而无法包含在快节奏的开发流程中。这就是为什么在大多数情况下，此类测试由专门的 QA 专家单独维护，编写它们通常不被认为是开发人员的工作。
　　集成测试是介于单元测试和完整端到端测试之间的部分，通常被完全忽略：因为不清楚在哪个级别上进行集成，以及如何构建和组织这样的测试，或者担心它们可能会失控。许多开发人员宁愿避免它们，而倾向于选择更明确的单元测试。
　　由于这些原因，在开发期间完成的所有测试通常都位于金字塔的最底部。事实上，这种情况非常普遍，以至于测试和单元测试现在实际上是彼此的同义词。而且这种概念的混淆会通过会议演讲、博客文章、书籍甚至一些 IDE 进一步传播。
　　虽然测试金字塔作为解决软件测试问题是一个伟大的尝试，但这种模型显然存在许多问题。它所依赖的假设可能并不适用于所有情况，尤其是高层次的测试将使测试变得缓慢或困难这个前提。
　　人类自然地倾向于依赖那些更有经验的人传递的信息，这样我们就可以从过去几代人的知识中受益，并将我们的第二思维应用到更有用的事情上。这个重要的进化特征，使我们的物种非常适合生存。
　　然而，当我们将经验作为指导方针时，我们容易不加思考地就认为它们本身就是好的，而忘记了它们与环境的相关性。现实情况是，环境会发生变化，曾经完全合理的结论（或最佳实践）可能不再适用。
　　用户行为驱动的测试
　　从根本上来说，测试的价值体现在测试能否确定软件正常工作。我们对测试越有信心，在变更代码时就越不需要依靠自己进行回归测试来发现潜在的缺陷，因为我们相信测试会为我们做到这一点。
　　反过来，这种对测试的信心取决于测试是否与实际用户行为相似。在不了解任何内部细节的情况下，在系统边界运行的测试场景必然会比在较低级别运行的测试为我们带来更多的信心。
　　从本质上讲，我们从测试中获得的软件开发的信心是衡量测试价值的主要指标。我们的目标也是尽可能的提高该项指标。
　　当然，也需要考虑其他因素的作用，例如成本、速度、并行化执行的能力等等，这些都很重要。测试金字塔对这些因素如何相互关联做出了强有力的假设，但这些假设并不普遍存在。
　　此外，这些因素对于增强信心没那么重要。一个测试需要很长时间才能运行完成，但提供了很多对代码的信心，仍然比一个非常快速和简单但什么都没做的单元测试有用得多。
　　出于这个原因，我发现应该尽可能地编写高度集成的测试，并且同时保证速度和复杂性在合理范围内。
　　这是否意味着我们编写的每个测试都应该是端到端的测试？答案是否定的，但我们应该尽可能朝着这个方向努力，同时将不利因素保持在可接受的水平。
　　可接受的水平应视具体项目开发上下文而定。归根结底，这些测试由开发人员编写并在开发过程中使用，这意味着它们不应该成为维护的负担，并且应该可以在本地构建和 CI 上运行。
　　这样做意味着您最终用例集中可能会有一批集成规模不同的测试用例，并且似乎没有清晰的代码结构。在单元测试中不会遇到这个问题，因为每个测试都与特定的方法或函数耦合，因此单元测试的结构通常映射了代码本身的结构。
　　需要说明的是，有没有清晰的结构并不重要，因为是否按类或模块组织测试并不重要，清晰的结构只是单元测试的副作用。相反，测试应该按照它们要验证的实际面向用户的功能进行划分。
　　此类测试基于软件的功能需求，描述软件具有哪些功能以及它们如何工作，因此通常被称为功能测试。功能测试不是测试金字塔中的某一层，而是与之正交的一个概念。
　　与流行的观点相反，编写功能测试不需要您使用 Gherkin 或 BDD 框架，它与单元测试使用相同的工具。