导入
导论
了解测试的清晰性并避免复杂性。
随着 Rails 社区的成熟，Rails 开发者越来越频繁地面对包含多年开发成果的代码库和测试套件。因此，关于如何随时间推移管理复杂性的设计策略，引发了大量讨论。
然而，关于哪些实践能让测试和测试套件长期保持价值的讨论却少得多。随着应用规模扩大、测试套件运行时间变长、复杂性增加，我们该如何编写真正有用的测试，同时又不阻碍未来的开发？
在本章中，我们将学习多种评估方法，判断我们编写的测试是否真正带来价值，并尽可能降低维护成本。
最关键的一点
让我们来看看一些最佳实践。
测试的清晰性
这是关于自动化测试风格和结构方面最核心的建议：测试验证代码，但测试本身没有任何验证。让测试尽可能清晰、易于维护，是确保其可靠性的最佳方式。
注意： 测试也是代码。更具体地说，测试是那些自身没有测试的代码。
在实践中，这意味着应避免在测试代码中使用复杂的元编程或循环结构，这些结构可能使理解测试逻辑和分析失败原因变得困难。我们有时可能会出于便利，尝试在循环中调用 RSpec 的 `it` 方法，但这不是一个好主意。
尽管将非常相似的逻辑分别写在多个独立测试中看起来会增加代码量，但为每个测试提供一条独立的失败报告路径，能显著提升定位问题和隔离单个测试失败的效率。
如果某种编程实践或工具行之有效，那么遵循或使用它将有助于实现以下目标：
- 在短期内轻松添加所需代码；
- 长期持续向项目中添加新功能。
Ruby 和 Rails 生态系统中的各类 gem 帮助我们达成第一个目标（Rails 本身也属于此类）。测试通常被认为主要服务于第二个目标。这没错，但人们常常误以为测试对长期应用健康唯一的贡献，就是验证应用逻辑和防止回归。实际上，测试驱动开发之所以长期受益，正是因为高质量的测试能够推动模块化设计的形成。
...