BDD测试结构

Question

我正在深入凯巴拉和rspec，从TDD转移到BDD。

我的生成器制作了大量的目录和规范测试，

目录结构与此类似：

     spec
        controllers
        models
        requests
        routing
        views

我认为这大部分是TDD而不是BDD。如果我读到这里

“一种很好的测试策略是用单元测试广泛地覆盖数据层，然后跳过所有的测试直到接受测试。这种方法提供了很好的代码覆盖率，并构建了一个测试套件，它可以在更改的代码基中灵活使用。”

然后我想事情应该完全不同了

字里行间的东西：

     spec
         models
         acceptance

基本上，我取出控制器、请求、视图和路由，以便在Capybara，Rspec的验收目录中实现测试。

这对我来说是有意义的，尽管我不确定这是否是标准/通用的方法。

你的方法是什么？

谢谢，朱利奥

Answer 1

tl;dr这不是一个标准的方法。

如果你只测试模型和功能规格..。然后你就错过了中间的部分。

您可以说："method X破坏了Widget模型“，或者说”在创建小部件时出现了问题“，但是您对其他任何事情都一无所知。

如果什么东西坏了，是控制器吗？路线？在两个人之间交手？

很高兴有：

1. 在模型级别进行非常彻底的测试(例如检查每个验证、每个方法、每个基于传入参数的选项)
2. 在中间进行粗略的测试，以确保子系统按照预期的方式工作(例如控制器设置了正确的变量，并在一定的情况下调用了正确的模板/重定向)。
3. 作为烟雾测试的整体特性测试(如用户可以通过愉快的路径和一切按照他们期望的方式工作)。如果他们输入了不好的东西，应用程序就会弹出正确的错误信息，并重新显示表单以修复问题)

别忘了，在你的应用程序中，模型不是唯一的类。所有的类都需要某种测试。控制器也是类。如表单和服务对象、邮递员等。

尽管如此，人们通常认为视图测试是过火的。我也不热衷于请求-测试我们的路由测试自己(除非我有一些复杂的东西，我想正确地工作，例如在一个路线上的许多可选的参数映射到有趣的搜索模式)