R规格大型规格文件组织

发布于 2025-01-05 02:00:31 字数 307 浏览 0 评论 0原文

我只是想知道其他人如何组织大型规范文件(尤其是模型),其中许多上下文和部分组织在描述块中,以进行验证和其他可以以某种有意义的方式分组的规范。

你们是否将有关模型的所有规格保留在该模型的同一规格文件中,或者以某种方式拆分为模块?

到目前为止,我从来没有太关心这个问题,但我想知道其他人在做什么,因为似乎没有就最佳实践等达成某种共识。

我有一些模型的相当大的规格文件,我想将它们组织成较小的文件,并且不同模型之间几乎没有共享的功能,所以我不确定共享示例是否是解决这个问题的方法(不管可重用性)或者是否有更好的方法。有什么建议吗?

提前致谢。

I was just wondering how others organise large spec files (especially for models) with many contexts and sections organised in describe blocks for validations and other specs that can be grouped in some meaningful way.

Do you guys keep all the specs concerning a model in the same spec file for that model, or do you split into modules in a way or another?

I have never cared too much about this so far but I am wondering what others do, as there doesn't seem to be some sort of agreement around a best practice or such.

I've got some pretty large spec files for some models that I'd like to organise into smaller files, and there is little to no functionality shared across different models so I am not sure whether shared examples would be the way to go about this (regardless reusability) or whether there is some better way. Any suggestions?

Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

So尛奶瓶 2025-01-12 02:00:31

嵌套上下文可以在这里为您提供帮助,但请保持浅层(通常深一层)。每个示例中需要考虑两个变量:给定(起始状态)和正在调用的方法。您可以按方法或状态对事物进行分组:

# by method
describe Stack do
  describe "#push" do
    it "adds an element to an empty stack"
    it "adds an element to a non-empty stack"
  end

  describe "#pop" do
    it "returns nil from an empty stack"
    it "returns the last element of a non-empty stack"
    it "removes the last element from a non-empty stack"
  end
end

# by state
describe Stack do
  context "when empty" do
    specify "push adds an element"
    specify "pop returns nil"
  end

  context "when not empty" do
    specify "push adds an element"
    specify "pop returns last element"
    specify "pop removes last element"
  end
end

我已经使用了这两种方法,并且发现它们都工作得非常好和非常糟糕。这两种方法的关键在于,当您从上到下阅读时,示例会讲述一个故事。随着需求的发展,这意味着您需要检查此文件,就像检查实现代码一样。
检查规范是否有意义的一个简单方法是使用文档格式化程序运行它:

rspec stack_spec.rb --format documentation

这会按顺序吐出所有名称(假设您没有使用 --order rand):

Stack
  #push
    adds an element to an empty stack
    adds an element to a non-empty stack
  #pop
    returns nil from an empty stack
    returns the last element of a non-empty stack
    removes the last element from a non-empty stack

或者

Stack
  when empty
    push adds an element
    pop returns nil
  when not empty
    push adds an element
    pop returns last element
    pop removes last element

一旦您看到此输出,它就会您非常清楚您所使用的组织是否有意义。

Nested contexts can help you here, but keep it shallow (typically one level deep). There are two variables to consider in each example: givens (starting state) and what method is being invoked. You can group things by method or state:

# by method
describe Stack do
  describe "#push" do
    it "adds an element to an empty stack"
    it "adds an element to a non-empty stack"
  end

  describe "#pop" do
    it "returns nil from an empty stack"
    it "returns the last element of a non-empty stack"
    it "removes the last element from a non-empty stack"
  end
end

# by state
describe Stack do
  context "when empty" do
    specify "push adds an element"
    specify "pop returns nil"
  end

  context "when not empty" do
    specify "push adds an element"
    specify "pop returns last element"
    specify "pop removes last element"
  end
end

I've used both approaches and seen them both work really well and really badly. The key to either approach is that the examples tell a story as you read from top to bottom. As requirements evolve, this means you need to review this file, just as you do your implementation code.
An easy way to check that the spec makes sense is to run it with the documentation formatter:

rspec stack_spec.rb --format documentation

This spits out all the names in order (provided you're not using --order rand):

Stack
  #push
    adds an element to an empty stack
    adds an element to a non-empty stack
  #pop
    returns nil from an empty stack
    returns the last element of a non-empty stack
    removes the last element from a non-empty stack

or

Stack
  when empty
    push adds an element
    pop returns nil
  when not empty
    push adds an element
    pop returns last element
    pop removes last element

Once you see this output, it'll be pretty clear to you whether the organization you're using makes sense or not.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文