[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: Test system for module methods
From:       Robert Klemme <shortcutter () googlemail ! com>
Date:       2017-03-29 5:11:16
Message-ID: CAM9pMnOVfwYtN5pDzZjaoVcr=WzBYkDAMoE9zNWbriyDS1uL-w () mail ! gmail ! com
[Download RAW message or body]

On Wed, Mar 29, 2017 at 3:12 AM, Matthew Kerwin <matthew@kerwin.net.au> wrote:

> Yeah, if you're testing instance methods defined in a module, rigging up a
> dummy class and a dummy instance is definitely the way to go.  (I'm not
> going to call it a mock or a stub, because there's a whole world of
> terminology arguments to be had there
> <https://en.wikipedia.org/wiki/Test_double>.)

You do not need a class for that, an instance is sufficient since with
an empty class you cannot rely on methods but those defined in Object
anyway,

module A
  def add(x, y)
    x + y
  end
end

irb(main):007:0* Object.new.extend(A).add(4, 7)
=> 11

But neither approache will work for modules that expect methods to be
there, e.g. like Enumerable. There you will at least have to mock
methods.

class EnumTest
  include Enumerable
  def each; yield 1; yield 5; self; end
end

irb(main):012:0> EnumTest.new.to_a
=> [1, 5]

Cheers

robert

-- 
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic