我是黄瓜测试的新手，我试图了解何时使用黄瓜，何时使用RSpec。对于我的模型，我知道我应该用RSpec测试它们，而且我知道如果我写Cucumber故事，我不需要编写RSpec请求规范。我不知道什么时候使用视图和控制器。我是否应该使用RSpec来测试我的视图和控制器，或者我可以跳过它们，因为我正在使用Cucumber进行更高级别的测试?任何建议将非常感激!谢谢!
我使用RSpec来驱动模型的开发和测试，并在某种程度上驱动控制器，使用Cucumber来驱动视图的开发和测试(以及随后它们与控制器的集成)。
我不认为编写Cucumber测试可以让我"跳过"编写RSpec测试，因为在创建任何视图之前，很多开发都是在模型层进行的。
如果您继续编写Cucumber场景而不是单元测试，那么您可能会发现您的测试运行起来非常慢。如果测试很慢，您可能不会经常运行它们，因此您的开发速度将会减慢。
你可以使用RSpec在和Cucumber一样的级别上进行集成测试。如果您需要与非开发人员共享和讨论特性，那么Cucumber是一个巨大的帮助。但即使你是一个单独的开发人员，Cucumber也可以作为你需要的行为和底层实现之间的"心理守卫"。
大多数人遵循的标准实践是为模型编写大量的单元测试，为控制器编写最少的单元测试，而很少为视图编写任何单元测试。然后，您将使用Cucumber来检查所有内容是否正确交互(确保您的场景涵盖了控制器和视图中的任何循环/条件)。
我不确定是否可以在这里推荐一本书，但是The RSpec book by David Chelimsky (ISBN 9781934356371)确实提供了一个很好的实际示例，说明如何将Cucumber和RSpec交叉使用以行为驱动Ruby中的小型命令行游戏的开发。
简而言之:写下你的黄瓜功能采用的角度来看你的终端用户,和你RSpec规格使用自己的观点作为一个开发人员是一个很好的平衡执行速度测试套件的测试粒度(如何精确测试失败时的出错信息)和文档覆盖(黄瓜特性可以被看作是一个总是最新的文档——自己的RSpec文档是一个很好的例子)。
这只是一个可能对您有帮助的小补充。许多人认为(我也认为)cucumber对程序员来说是一个麻烦的测试框架，而不是一个实用的测试框架。只要您不需要与不太了解编程的客户讨论场景，我强烈建议您不要使用cucumber。在这一点上我同意卫生部的观点。但是RSpec，使用甚至滥用:)