为覆盖范围非常大的测试构建rspec文件结构和代码?

我刚刚开始研究一个用rspec编写了2万个单元测试的项目(这个项目本身并不是用ruby编写的,只是测试用例)。随着更多功能的增加,当前的测试用例数量预计将在未来急剧增长。已经发生的事情(在很长的一段时间内)是,rspec开始是测试这个项目的一个特别好的解决方案,但是随着项目的发展,rspec测试用例的相当特殊的结构已经严重地折磨了他们。他们遇到的最大问题之一是测试代码中的分类法——在测试用例中命名测试用例、设备、帮助程序代码等的结构(或缺少)。

正如您所想象的,对于20k单元测试,有许多名称非常相似的方法,使用的帮助器方法都是从全局命名空间加载的。

为了突出显示问题所在的一个区域,这个应用程序中有大约10个数据库。正在检查表/列/视图/约束/存储过程/的结构…对于所有这些数据库来说(相当合理地)都包含在现有的rspec单元测试中。但是,此数据库集合中需要检查的DDL实体总数可能超过10000个,涵盖了整个数据库结构检查范围 和 要能够有选择地测试数据库结构的子集,需要:

• 10000种不同的方法(我马上排除了这个选项!)

• 测试用例中相当复杂的命名约定(例如,包含db name+table name+column name+…),
• 或传递数据库名、表名、列名…到泛型方法
• 或者通过名称空间分离关注点(我不知道在rspec中有一种优雅的可伸缩的方式来实现这一点)。
• 或者一些聪明的元编程(我怀疑这最终会使一个已经很混乱的结构变得更加难以遵循)。

据我所知,现在存在的只是上面的一点,没有太多明显的计划……

你有什么建议或参考资料我可以看一下,试图理顺这个混乱,并给他们一些可伸缩的结构,他们的rspec测试?特别是,关于如何为非常大的项目构建各种rspec文件的建议将非常受欢迎。