测试
为什么要进行自动测试？
以下是我们应进行自动化测试的众多好理由中的一些：
您可以更快地对代码进行增量更新。ROS 有数百个相互依赖的包，因此很难预测小改动可能导致的问题。如果您的更改通过了单元测试，您可以更有信心地认为您没有引入问题 — 或者至少这些问题不是您的错。
您可以更有信心地重构代码。通过单元测试可验证您在重构时没有引入任何错误。这让您摆脱了对更改的恐惧！
它可设计出更好的代码。单元测试迫使您编写代码，以便更容易测试。这通常意味着将底层函数和框架分开，这是我们设计 ROS 代码的目标之一。
它们可防止重复出现错误（错误回归）。为修复的每个错误编写单元测试是一种很好的做法。事实上，在修复错误之前编写单元测试。这将帮助您准确地，甚至确定地重现错误，并更准确地了解问题所在。因此，您还可以创建一个更好的补丁，然后可以使用回归测试对其进行测试以验证错误是否已修复。这样，如果稍后修改代码，错误就不会意外地重新引入。这也意味着更容易说服补丁的审阅者问题已解决，并且贡献是高质量的。
其他人可以更轻松地处理您的代码（一种自动文档形式）。当您进行更改时，很难确定您是否破坏了别人的代码。单元测试是其他开发人员验证其更改的工具。自动测试记录您的编码决策，并自动向其他开发人员传达他们的违规行为。因此，测试成为您的代码的文档——大多数时候不需要阅读的文档，当需要检查时，测试系统将准确指示要阅读的内容（哪些测试失败）。通过编写自动测试，您可以让其他贡献者更快地完成工作。这改善了整个 ROS 项目。
如果我们有自动化单元测试，那么成为 ROS 贡献者就会容易得多。新的外部开发人员很难为您的组件做出贡献。当他们更改代码时，他们通常是盲目地进行，并受到大量猜测的驱使。通过提供自动化测试工具，您可以帮助他们完成任务。他们会立即获得有关其更改的反馈。为项目做出贡献变得更加容易，新贡献者也更容易加入。而且，他们的首次贡献质量更高，从而减少了维护人员的工作量。双赢！
自动测试简化了维护工作。特别是对于变化较慢且大多需要更新到新依赖项的成熟软件包，自动测试套件有助于非常快速地确定软件包是否仍然有效。这使得决定软件包是否仍然受支持变得容易得多。
自动测试放大了持续集成的价值。回归测试以及基于场景的常规需求测试共同构成了组件的自动化测试整体。您的组件会根据其所依赖的其他 API 的演变情况进行更好的测试（CI 服务器会更好、更准确地告诉您代码中出现了哪些问题）。
编写测试最重要的好处可能是测试让您成为好公民。 测试会影响长期质量。 这是许多开源项目中广为接受的做法。 通过编写回归测试，您可以为 ROS 生态系统的长期质量做出贡献。
这一切都是免费的吗？
当然，没有免费的午餐。 要获得测试的好处，需要进行一些投资。
您需要开发一个测试，这有时可能很困难或成本高昂。有时它也可能不简单，因为测试应该是自动的。如果您的测试涉及特殊硬件（它们不应该：尝试使用模拟、模拟硬件或将测试范围缩小到较小的软件问题）或需要外部环境（例如人工操作员），事情就会变得特别棘手。
需要维护回归测试和其他自动测试。当组件的设计发生变化时，许多测试会失效（例如，它们不再编译，或抛出与 API 设计相关的运行时异常）。这些测试失败不仅是因为重新设计重新引入了错误，还因为它们需要更新到新设计。有时，在进行更大规模的重新设计时，旧的回归测试应该被放弃。
大量测试可能需要很长时间才能运行，这会增加持续集成服务器的成本。