20

什么被认为是可靠的规格？

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

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

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

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

  1. 填空...
  2. ?

扩展这个规范应该和不应该包含的内容的列表会很棒。

我还想编制一份技巧和建议清单。例如：

关键字“应该”有点多余。

例子：

这个：

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规范。” -@yfeldblum（见下面的答案）

在网上你会发现很多文章描述了关于如何测试基本东西的不切实际的场景，但除此之外，你只能靠自己了。如果我要写一篇关于这个主题的文章，我只会链接到我的测试（例如在 github 上），然后彻底注释其中一个或几个规范......这似乎是写一篇关于 rspec 的文章的最佳方式，在我看来。我会自己做，但我还没有完全做到。

如果您投票关闭此帖子，那很好，只需尝试就您认为此帖子的所属位置发表评论或建议。谢谢！

4

4 回答 4

10

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

描述方法

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

每个测试用例一个断言

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

避免将数据保存到数据库

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

@user.build(:something) 而不是 @user.create(:something)

边缘和无效案例

这不是 Rspec 特有的，但确保在测试中涵盖边缘情况很重要。当您的项目增长并且易于维护时，这将有很大帮助。

语境

我个人非常喜欢 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 测试用例。但这应该足以开始编写很棒的测试用例了。

于 2012-08-09T09:37:31.787 回答
5

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

  • 每个例子只有一个断言。不要在同一个例子中断言两件事。一个示例是传递给it、its或的块specify。
于 2012-08-08T00:01:44.130 回答
0

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

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

于 2014-01-08T00:21:16.843 回答
0

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

示例控制器操作的测试应如下所示：

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

您可以在此处找到有关控制器测试的更多信息。

于 2018-03-01T13:46:58.030 回答