我刚刚开始研究一个用 Rspec 编写的超过 20k 单元测试的项目（项目本身不是用 Ruby 编写的；只是测试用例）。随着更多功能的添加，当前的测试用例数量预计将在未来急剧增长。已经发生的事情（在很长一段时间内）是 RSpec 开始成为测试这个项目的一个特别好的解决方案，但是随着项目的发展，他们的 RSpec 测试用例的相当特别的结构已经严重地咬了他们。他们遇到的最大问题之一是他们的测试代码中的分类法——在他们的测试用例中命名他们的测试用例、固定装置、帮助代码等的结构（或缺乏）。
正如你所想象的，在超过 20k 的单元测试中，有很多名称非常相似的方法，使用的辅助方法都是从全局命名空间加载的。
为了突出问题所在的一个领域，这个应用程序中有大约 10 个数据库。检查所有这些数据库的表/列/视图/约束/存储过程/...的结构是现有 RSpec 单元测试中涵盖的内容（相当合理）。但是，这个数据库集合中需要检查的 DDL 实体总数可能 >10000；涵盖整个 DB 结构检查范围并能够选择性地仅测试 DB 结构的子集需要：
10000 种不同的方法（我立即排除了该选项！）
- 测试用例中相当复杂的命名约定（即包含 DB 名称 + 表名称 + 列名称 + ...），
- 或将数据库名称、表名、列名等传递给通用方法
- 或者通过命名空间分离关注点（我不知道在 RSpec 中有一种优雅的可扩展方式），
- 或者一些聪明的元编程（我怀疑最终可能会使已经混乱的结构更加难以遵循）。
据我所知，现在存在的只是上述所有内容，没有很多明显的计划......
您是否有任何提示或参考资料可以让我尝试理顺这种混乱，并为他们的 RSpec 测试提供某种可扩展的结构？特别是，非常欢迎关于如何为非常大的项目构建各种 RSpec 文件的建议。