Couldn't you have the same programming challenges, but not have STDIN/OUT?

    $ irb
    2.4.1 :001 > 1.class
     => Integer 
    2.4.1 :002 > class Integer
    2.4.1 :003?>   def 1
    2.4.1 :004?>     2
    2.4.1 :005?>     end
    2.4.1 :006?>   end
    SyntaxError: (irb):3: syntax error, unexpected tINTEGER
    def 1
         ^
    (irb):6: syntax error, unexpected keyword_end, expecting end-of-input

More evidence:

    2.4.1 :001 > class Integer
    2.4.1 :002?>   define_method(:one) { 1 }
    2.4.1 :003?>   end
     => :one 
    2.4.1 :004 > Integer.one
    NoMethodError: undefined method `one' for Integer:Class
    2.4.1 :005 > Integer.new.one
    NoMethodError: undefined method `new' for Integer:Class
    2.4.1 :006 > Integer.new
    NoMethodError: undefined method `new' for Integer:Class
    2.4.1 :007 > class Klass
    2.4.1 :008?>   define_method(:one) { 1 }
    2.4.1 :009?>   end
     => :one
    2.4.1 :010 > Klass.one
    NoMethodError: undefined method `one' for XY:Class
    2.4.1 :011 > Klass.new.one
     => 1 

TLDR MRI gets the value of the number directly from value of the C pointer and saves the lookup. It's a 1 in the lowest bit and the integer value in the others. That's why 0.object_id == 1, 1.object_id == 3, etc

Obviously that's implementation dependent but I guess no Ruby implementation is going us to redefine integers if MRI does not.

http://demin.ws/blog/english/2012/09/27/fcode/

A more sensible alternative would probably be to serialise the assert_equal parameters and check the results externally.

Adding negative tests (using `not a == b` to avoid the same monkeypatching of !=) would also help