决定测试内容，而非测试本身是什么，对于所有团队而言是个关键议题。测试是实现最终目标的一种方式，而确定对代码库中哪些部分进行优先测试则是一项挑战。
决定测试的优先顺序应当基于你的代码库及团队目标。但需要注意的是，尽管撰写众多小型测试（比如位于测试金字塔底层的单元测试）耗时少且能涵盖广泛的代码，这并不意味着它们能显著降低项目的整体风险。
通过考虑你的应用程序、网站或库的主要使用场景，你可以确定首先需要测试什么。这可能意味着对网站的关键部分，即那些构成用户体验核心的组件，进行组件测试。比如，一个让用户上传和管理时间序列数据的网站的开发者应该模拟并测试用户可能以各种方式进行这些操作的场景。
获得尽可能多的信息是另一种优先测试的情况。如果你的代码库中有一部分是“危险”的、老旧的或编写不良的，并且你的团队成员都不愿意处理它，那么在你选择进一步忽视它或是重构它之前，为它建立测试以使其行为更加稳定可能是个不错的选择。可以将其视为给一个已经被废弃但还在存放数据中心的建筑加上的支架。
维度
我们介绍了测试金字塔或其他形状的测试，但这些通常只呈现测试的单一维度：一条线，从范围小、简单的单元测试延伸到复杂、广泛的测试——单元测试、集成测试和端到端测试。
然而，可能的测试类型的长列表中有些并不反映复杂性层次，而是反映了测试的目的或方法。举个例子，冒烟测试属于不同的测试类别，它们可以是单元测试、端到端测试或其他形式的测试，目的是让测试人员对项目的有效状态有整体的信心。视觉测试同样可以针对小型组件进行，或者应用于你的整个网站。
每个代码库都有其特定的要求。比如，在你的代码库中，实现某一个功能的一致性可能远比其他方面更为关键，这就需要编写多种测试来保证该功能的准确性。新功能的测试往往不仅限于某个单独的组件、函数或方法，它对整个项目的影响可能是全面的，涉及多个层面。
你所面临的测试优先事项还可能与你的商业需求紧密相关。对于那些技术含量高的系统来说，可能需要进行一系列复杂的单元测试，以确保某个特别算法能够精确执行。相反，对于那些交互性强的工具，它们可能会更侧重于视觉测试或端到端测试，以此来验证复杂的触控输入是否能产生预期的响应。
你的测试策略
专注于检验你代码库的实际应用场景，不管它们大小如何。设想用户可能会如何使用你的项目——无论是某个单独的组件、一个底层函数，还是一个完整的端对端使用案例。（这也能帮助你发现在任何层面上的设计缺陷，特别是当你意识到测试过程与代码的互动不够流畅时。）
确保每个测试案例都有一个清晰的目标极为关键。正如你的业务代码一样，庞大而包罗万象的测试可能会变得难以管理。
关于测试驱动开发
测试驱动开发（TDD）是一种特别的测试方法，它的特点在于首先编写会失败的测试，这种方法与测试的规模或类型无关。无论是手动测试还是自动化测试，都是如此：首先明确你想要达成的目标，找出现有解决方案或代码中的不足，然后利用这些失败的测试指引你找到解决之道。
显然，试图在开始构建一个不存在的组件之前，就想要测试每一种可能的情况，这并不现实。TDD 有其适用的场景，在代码库逐渐复杂化时，它可以发挥重要作用。
TDD 同样适用于错误修复过程。如果你能把重现一个错误的步骤转换成代码，那么就可以创建一个自动化测试，这个测试起初会显示失败状态。待到你解决了这个错误，如果测试显示通过，就意味着你可以确定错误被成功修复，而不需要进行手动验证。
黑盒与白盒
黑盒与白盒是指测试系统各部分时采取的方法。所谓黑盒，意味着你不能看见其内部机制，比如说，通过使用一个类的公共接口来进行测试，而不去深究它内部的具体实现。
通常情况下，除非有充分的理由，否则优先选择黑盒是一个比较好的做法。这样做可以让你更关注于组件是如何被使用的，而不是它们的内部是如何工作的。如果你的测试只依赖于代码的“公共”接口（这里的“公共”并不一定意味着对最终用户开放，也可能是对代码中其他部分开放的），这样你就可以在重构和优化代码的同时，确信黑盒任何变更都会被测试捕捉到。
想让白盒变黑，一个方法是加入可配置的元素，例如抽象代码的依赖，或者使用回调函数来监控状态，而不是让状态与其他系统紧密绑定。这样做可以让你的代码更加独立，方便你创建测试。另一种方法是，当你的代码需要与其他系统交互时，可以使用 mock。