Is it idiomatic Ruby to add an assert( ) method to Ruby's Kernel class?

RubyAssertXunit

Ruby Problem Overview


I'm expanding my Ruby understanding by coding an equivalent of Kent Beck's xUnit in Ruby. Python (which Kent writes in) has an assert() method in the language which is used extensively. Ruby does not. I think it should be easy to add this but is Kernel the right place to put it?

BTW, I know of the existence of the various Unit frameworks in Ruby - this is an exercise to learn the Ruby idioms, rather than to "get something done".

Ruby Solutions


Solution 1 - Ruby

No it's not a best practice. The best analogy to assert() in Ruby is just raising

 raise "This is wrong" unless expr

and you can implement your own exceptions if you want to provide for more specific exception handling

Solution 2 - Ruby

I think it is totally valid to use asserts in Ruby. But you are mentioning two different things:

  • xUnit frameworks use assert methods for checking your tests expectations. They are intended to be used in your test code, not in your application code.
  • Some languages like C, Java or Python, include an assert construction intended to be used inside the code of your programs, to check assumptions you make about their integrity. These checks are built inside the code itself. They are not a test-time utility, but a development-time one.

I recently wrote solid_assert: a little Ruby library implementing a Ruby assertion utility and also a post in my blog explaining its motivation.. It let you write expressions in the form:

assert some_string != "some value"
assert clients.empty?, "Isn't the clients list empty?"

invariant "Lists with different sizes?" do
    one_variable = calculate_some_value
    other_variable = calculate_some_other_value
    one_variable > other_variable
end    

And they can be deactivated so assert and invariant get evaluated as empty statements. This let you avoid any performance problem in production. But notice that The Pragmatic Programmers recommend against deactivating them. You should only deactivate them if they really affect to the performance.

Regarding to the answer saying that the idiomatic Ruby way is using a normal raise statement, I think it lacks of expressivity. One of the golden rules of assertive programming is not using assertions for normal exception handling. They are two completely different things. If you use the same syntax for the two of them, I think you code will be more obscure. And of course you lose the capability of deactivating them.

You can be convinced that using assertions is a good thing because two must-read classic books like The Pragmatic Programmer From Journeyman to Master and Code Complete dedicate whole sections to them and recommend their use. There is also a nice article titled Programming with assertions that illustrate very well what is assertive programming about and when to use it (it is based in Java, but concepts apply to any language).

Solution 3 - Ruby

What's your reason for adding the assert method to the Kernel module? Why not just use another module called Assertions or something?

Like this:

module Assertions
  def assert(param)
    # do something with param
  end
  
  # define more assertions here
end

If you really need your assertions to be available everywhere do something like this:

class Object
  include Assertions
end

Disclaimer: I didn't test the code but in principle I would do it like this.

Solution 4 - Ruby

It's not especially idiomatic, but I think it's a good idea. Especially if done like this:

def assert(msg=nil)
    if DEBUG
        raise msg || "Assertion failed!" unless yield
    end
end

That way there's no impact if you decide not to run with DEBUG (or some other convenient switch, I've used Kernel.do_assert in the past) set.

Solution 5 - Ruby

My understanding is that you're writing your own testing suite as a way of becoming more familiar with Ruby. So while Test::Unit might be useful as a guide, it's probably not what you're looking for (because it's already done the job).

That said, python's assert is (to me, at least), more analogous to C's assert(3). It's not specifically designed for unit-tests, rather to catch cases where "this should never happen".

How Ruby's built-in unit tests tend to view the problem, then, is that each individual test case class is a subclass of TestCase, and that includes an "assert" statement which checks the validity of what was passed to it and records it for reporting.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionAndrew Harmel-LawView Question on Stackoverflow
Solution 1 - RubyJulikView Answer on Stackoverflow
Solution 2 - RubyjmanrubiaView Answer on Stackoverflow
Solution 3 - RubyChristoph SchiesslView Answer on Stackoverflow
Solution 4 - RubyregularfryView Answer on Stackoverflow
Solution 5 - RubyAtiaxiView Answer on Stackoverflow