我刚刚开始研究一个项目，该项目有超过 20k 个用 Rspec 编写的单元测试(该项目本身不是用 Ruby 编写的；只是测试用例)。随着更多功能的添加，当前的测试用例数量预计 future 将大幅增长。已经发生的事情(在很长一段时间内)是，RSpec 最初是测试该项目的特别好的解决方案，但随着项目的发展，其 RSpec 测试用例的相当特殊的结构对他们造成了严重影响。他们遇到的最大问题之一是测试代码中的分类 - 测试用例中命名测试用例、固定装置、帮助程序代码等的结构(或缺乏)。
正如您所想象的，对于超过 20k 的单元测试，有很多名称非常相似的方法，使用的辅助方法都是从全局命名空间加载的。
为了突出显示问题所在的一个区域，该应用程序中有大约 10 个数据库。检查所有这些数据库的表/列/ View /约束/存储过程/...的结构(相当合理)包含在现有的 RSpec 单元测试中。然而，这个数据库集合中需要检查的 DDL 实体总数可能>10000；覆盖数据库结构检查的整个范围并且能够有选择地仅测试数据库结构的子集需要:
-
10000 separate methods (and I'm ruling out that option straight away!)
- 测试用例中相当复杂的命名约定(即包含数据库名称 + 表名称 + 列名称 + ...)，
- 或通过，例如数据库名称、表名称、列名称...到通用方法
- 或者通过命名空间进行关注点分离(我不知道在 RSpec 中是否有一种优雅的可扩展方法)，
- 或者一些巧妙的元编程(我怀疑这最终可能会使本已困惑的结构变得更加难以理解)。
据我所知，现在存在的是上述所有内容，没有太多明显的计划......
您是否有任何提示或引用资料可供我引用，以尝试解决这个困惑问题，并为他们的 RSpec 测试提供某种可扩展的结构？特别是，关于如何为大型项目构建各种 RSpec 文件的建议将非常受欢迎。
最佳答案
The RSpec Book是有关 RSpec 提示和技巧以及一般 BDD 方法的优秀资源(尽管您的重点似乎更多是关于测试)。有多种方法可以简化和干燥规范，使其更易于管理，包括共享示例(第 12 章)和宏(第 17 章)。
我还推荐David Chelimsky's blog .
看起来您的项目仍然是一个真正的挑战。在您提到的方法中，我认为使用带有 DB、表和列作为参数的宏是最有前途的。
关于namespaces - 为覆盖范围非常大的测试构建 RSpec 文件结构和代码？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2189429/