在 Ruby 生产中使用断言...是还是否?

发布于 2024-10-30 18:35:35 字数 289 浏览 6 评论 0原文

所以,这就是交易。我目前在 Ruby on Rails 环境中工作,已经工作约 1 年了。在此之前,我在 C++/Java 领域工作了近十年。我(仍在)试图弄清楚 Ruby 的断言方式是什么。

我不担心技术细节。我知道 TestUnit 有可以在测试环境中使用的断言,并且我知道我可以将自己的断言方法添加到我的 Ruby 项目中,并在生产 Rails 中使用它们来锁定已知条件。问题是:Ruby 的方式是什么来确保代码中我知道应该/不应该发生的事情?

作为记录,我一直在测试中断言并在生产中提高。我仍然忍不住想念我的生产断言......

So, here's the deal. I'm currently working in a Ruby on Rails environment and have been for ~1 year now. Before that I was in C++/Java land for almost a decade. I'm (still) trying to figure out what the Ruby way is when it comes to asserts.

I'm not worried about the technical detail. I know TestUnit has asserts which can be used in the testing environment and I know I can add my own assert methods to my Ruby project and use them in production Rails to lock down known conditions. The question is: What is the Ruby way for ensuring something in code that I know should/not happen?

For the record, I've been asserting in tests and raising in production. I still can't help but miss my production asserts...

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

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

发布评论

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

评论(3

心是晴朗的。 2024-11-06 18:35:35

断言确实不应该在生产代码中使用,原因有两个。

  1. assert x 功能非常强大,因此很难阅读。使用 raise/if 组合可以增加可读性。

  2. assert 没有明确说明如果条件失败将会引发什么错误。同时,

    如果条件成立则引发 ObscureButInformitiveError

    让应用程序层进一步做一些相关的事情。例如向管理员发送电子邮件或写入特定日志。

Asserts really shouldn't be used in production code for two reasons.

  1. assert x is very functional, and as such hard to read. Using a raise/if combo adds readability.

  2. assert doesn't make it clear what error will be raised if the condition fails. While,

    raise ObscureButInformitiveError if condition

    lets the application layers further up do something relveant. Such as emailing an admin, or writing to a perticular log.

孤独患者 2024-11-06 18:35:35

让错误发生,然后检查日志中是否出了问题,然后修复它。
Rails 会自动捕获所有未捕获的异常,它只会弄乱发生错误的单个请求。

Let the error happen, then check the logs for what went wrong, then fix it.
Rails catches all uncaught exceptions automatically, it will only mess up the single request the error happened in.

软糖 2024-11-06 18:35:35

Ruby 中没有官方的非测试断言,但有 gem。

例如 Jim Weirich 的 Given 看起来很有希望。虽然它的主要重点是测试环境(rspec / minitest),但它还:

...提供了三个断言,用于
非测试/非规范代码。例如,这是一个平方根函数
配备前置条件和后置条件断言。

需要“给定/断言” 
需要“给定/模糊数”

包括给定::断言 
包括给定::模糊

def sqrt(n)   
  前提条件 { n >= 0 }   
  结果 = Math.sqrt(n)
  后置条件 { 结果 ** 2 == about(n) }   
  结果 
结尾 

要使用
非测试断言,您需要要求 'given/assertions'
文件,然后将 Given::Assertions 模块包含到任何内容中
类使用 Precondition / Postcondition / Assert 方法。代码
这些断言的块应该始终是常规的 Ruby true/false
value(RSpec 中的 should 和 Expect 方法不可用)。

注意,这个例子也使用了模糊数字匹配,但是
断言本身不需要。

There's no official non-test assertions in Ruby, but there are gems.

For instance Jim Weirich's Given looks promising. Although its main focus is testing environments (rspec / minitest), but it also:

... provides three assertions meant to be used in
non-test/non-spec code. For example, here is a square root function
decked out with pre and post-condition assertions.

require 'given/assertions' 
require 'given/fuzzy_number'

include Given::Assertions 
include Given::Fuzzy

def sqrt(n)   
  Precondition { n >= 0 }   
  result = Math.sqrt(n)
  Postcondition { result ** 2 == about(n) }   
  result 
end 

To use the
non-testing assertions, you need to require the 'given/assertions'
file and then include the Given::Assertions module into what ever
class is using the Precondition / Postcondition / Assert methods. The code
block for these assertions should always be a regular Ruby true/false
value (the should and expect methods from RSpec are not available).

Note that this example also uses the fuzzy number matching, but that
is not required for the assertions themselves.

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