Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Dec 31, 2014
  1. @brixen

    Archived project.

    brixen authored
Commits on Apr 14, 2011
  1. @brixen

    Finally cleaned up trailing whitespace in spec files.

    brixen authored brixen committed
Commits on Feb 22, 2010
  1. @brixen

    Standardize require lines.

    brixen authored
    Since 1.8 does not canonicalize the filename that is required,
    the same file can be required multiple time. This is particularly
    true for spec_helper.rb, however it could also affect execution
    of the specs. On 1.9, the path is canonicalized. Using
    File.expand_path should eliminate this difference on 1.8 and 1.9.
Commits on Oct 26, 2009
  1. @marcandre
Commits on Jan 19, 2009
  1. @brixen

    Removed specs mocking #respond_to? and #method_missing.

    brixen authored
    Ruby method dispatch behavior calls #method_missing if an instance has
    no method corresponding to a particular selector.  Ruby also defines a
    number of methods, for example, #to_ary, #to_int, #to_str, that form
    an interface to Ruby's ducktyping behavior. String methods, for
    instance, may call #to_str when passed an argument that is not a String.
    The point of the rubyspecs is to describe behavior in such a way that
    if two different implementations pass a spec, Ruby code that relies on
    behavior described by the spec will execute with the same result on
    either implementation.
    If a spec asserts that a method calls #to_int on an object, it is
    immaterial to the final outcome whether an implementation calls
    some way, or first calls #respond_to?(:to_int) and then calls #to_int.
    There are only two significant aspects to this from the perspective of
    user code (i.e. code using the interface, not code implementing the
    behavior): 1) #to_int is called and performs some action; or 2)
    It is conceivable that user code like the following exists:
      class Silly
        def method_missing(sym, *args)
          return 1 if sym == :to_int
    In such case, the behavior of the following code would be different:
      # The implementation calls #to_int without checking #respond_to?
      [1, 2].at(silly) # => 2
      # The implementation calls #respond_to? first
      [1, 2].at(silly) # => TypeError
    In the second case, the expected behavior is restored if the Silly
    class is modified to implement a #respond_to? for :to_int.
    The point is that it really is not sensible to implement an object
    that provides an interface but does not let the world know about it by
    either 1) defining the method properly, or 2) defining #respond_to? to
    indicate that the object provides the interface.
    If real-world code exists that _depends_ on this silly implementation
    (i.e. cannot be coded in a more realistic way), then we can revisit
    the utility of specs that require #respond_to? to be called.
    Otherwise, these specs are too tied to the implementation and impose
    an unrealistic burden on implementations that may exhibit perfectly
    compatible behavior but not call #respond_to?.
Commits on Dec 29, 2008
  1. @brixen
Something went wrong with that request. Please try again.