Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Apr 14, 2012
  1. @nurse
Commits on Dec 29, 2011
  1. @nurse

    Refix syntax error.

    nurse authored
  2. @nurse

    Fix description.

    nurse authored
  3. @nurse

    Follow OpenBSD 5.0's behavior.

    nurse authored
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 Feb 17, 2010
  1. @nurse
  2. @brixen
Commits on Jan 5, 2010
  1. @BanzaiMan
Commits on Feb 10, 2009
  1. @brixen

    Fixed use of guards in the specs.

    brixen authored
    See for the correct use
    of all the guards. In particular, note that the compliant_on/
    not_compliant_on guarded specs will always run on MRI. The
    deviates_on, extended_on, and not_supported_on never run on MRI.
    These latter three guards will now raise an exception if passed
    :ruby. Also, platforms like :windows are not proper for any of
    these implementation compliance guards.
    Use ruby_version_is or ruby_bug guards for version-specific specs
    or specs that expose bugs in MRI.
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.