Question

什么是固体规格？

我发现这是关于测试非常抽象的。我对模型，控制器和其他任何可以测试的答案感兴趣。有一个规范的规范会很酷，你知道我的意思吗？

模型规范应该（按照优先级和相关性的顺序）：

测试所有方法？
测试错误数组？
测试CRUD（以及如何）？
还有什么？

控制器/视图规范应该（按优先级/相关性顺序）：

填空......
？

很高兴扩展一个规范应该和不应该包含的列表。

我也想编制一系列技巧和建议。例如：

关键字“应该”是多余的。

示例：

这样：

it "should be invalid without a firstname"

会更好：

it "is invalid without a firstname"

另一个技巧是，使用expect而不是lambda来提高可读性：

lambda { ... }.should be_valid

更具可读性：

expect { ... }.should be_valid

我正在编写有关入门的有用文章列表，并将在这篇文章中分享这些文章。以下是我发现现在特别有用的一些内容。（如果看起来有帮助，请随意发布你的内容）。

http://everydayrails.com/2012/03/19/testing-series-rspec-models-factory-girl.html http://nelvindriz.tumblr.com/post/835494714/rspec-best-practices

有一个项目列表可以很好地实现测试。由于rspec是如此可读（至少每个人都这么说），所以获得一个链接列表会很棒，这些项目有很好的规范可供阅读。

“请参阅Mongoid specs以获取良好规格的示例。” - @ yfeldblum（见下面的答案）

在线你会发现很多文章描述了如何测试基本内容的不切实际的场景，但除此之外，你还可以自己分类。如果我要写一篇关于这个主题的文章，我会链接到我的测试（例如在github上），然后彻底注释其中一个或几个规范...这似乎是写一篇关于rspec的文章的最好方法，在我看来。我自己做，但我还没到那里。

如果你投票结束这个，那很好，只是试着留下你认为这篇文章所属的评论或建议。谢谢！

Answer 1

这实际上是一个很好的问题，因为当我开始使用测试用例时，我不确定什么是一个好的测试用例。以下是您可以遵循的一些事项。这份清单不是我的;但是从一些来源加上我的一些补充来编译。

描述方法

在描述方法时，实际描述您的方法是一种很好的做法：描述“#admin？”等。“。”是类方法的前缀，“＃”是实例方法的前缀。

每个测试用例一个断言

确保每个测试用例只有一个断言。这可以确保您的测试用例干净且易于理解;这是测试用例的重点，不是吗？：）

避免将数据保存到数据库

您可以动态构建对象并避免将数据保存到db。虽然您可以在每个测试用例之前清理数据库，但“不保存”将大大加快测试用例的速度。

@ user.build（：something）而不是@ user.create（：something）

边缘和无效案例

这不是Rspec特有的，但重要的是要确保测试中包含边缘情况。这有助于您的项目何时增长并且易于维护。

<强> contexting

我个人而言，在Rspec中我喜欢这么多，事实上我过度使用了背景。使用具有条件的上下文有助于划分测试用例。这是一个例子：

# Avoid
it "should have 200 status code if user is logged in" do
  response.should respond_with 200
end
it "should have 401 status code if user is not logged in" do
  response.should respond_with 401
end

# Use
context "when user is logged in" do
  it { should respond_with 200 }
end
context "when user is logged out" do
  it { should respond_with 401 }
end

使用主题

当你有很多与同一事物有关的测试用例时，你可以使用subject（）来确保你不重复自己。

# Avoid
it { assigns(:user).should be_valid }
it { assigns(:user).should_not be_dumb }
it { assigns(:user).should be_awesome }

# Use
subject { assigns("user") }
it { should be_valid }
it { should_not be_dumb }
it { should be_awesome }

在编写测试用例时，我尝试遵循以下几点。我相信还有很多东西可以改善Rspec测试用例。但这应该足以开始并编写出令人敬畏的测试用例。

Answer 2

有关良好规格的示例，请参阅Mongoid specs。

每个示例只有一个断言。不要在同一个例子中断言两件事。一个示例是传递给it，its或specify的块。

Answer 3

我按照教程学习Ruby on Rails，并且将Rspec作为测试驱动开发的一部分进行教学。这里的流程是编写一个失败的测试，编写代码以通过测试，然后通过测试。理由似乎是通过这样做 - 从一个失败的测试开始 - 你可以非常确定你的代码符合你的期望。因此，我认为一个好的规范可以确保您的代码能够实现其应有的功能。到目前为止，我还没有像其他海报所写的那样从教程中收集任何经验法则。

这里是链接：http://ruby.railstutorial.org/

Answer 4

当您编写控制器测试时，您希望测试控制器中的所有操作。

示例控制器操作的测试应如何显示：

describe "Stories" do
  describe "GET stories#index" do
    context "when the user is an admin" do
      it "should list titles of all stories"
    end

    context "when the user is not an admin" do
      it "should list titles of users own stories" do
    end
  end

  describe "GET stories#show" do
    it "should render stories#show template" do
    end
  end

  describe "GET stories#new" do
    it "should render stories#new template" do
    end
  end

  describe "POST stories#create" do
    context "with valid attributes" do
      it "should save the new story in the database"
      it "should redirect to the stories#index page"
    end

    context "with invalid attributes" do
      it "should not save the new story in the database"
      it "should render stories#new template"
    end
  end

  describe "DELETE stories#delete" do
    it "should delete the story from the database"
    it "should redirect to the stories#index page"
  end
end

您可以找到有关controller tests here的更多信息。

什么被认为是一个很好的规范？ Rspec初学者的例子

4 个答案: