From j at jonathanleighton.com  Tue Jul  3 15:30:53 2007
From: j at jonathanleighton.com (Jonathan Leighton)
Date: Tue, 03 Jul 2007 20:30:53 +0100
Subject: [mocha-developer] Testing a call to super
Message-ID: <1183491053.9151.14.camel@localhost.localdomain>

> I can't think of a simple way offhand. Can you give an example (both test &
> application code) to explain why you want to do it?

Sorry for my slow reply to this, I've been pretty busy.

Sometimes you might have a concrete subclass of an abstract class, and
some functionality which the abstract class provides must happen in
order for the method to be "successful". In this case the concrete class
will be buggy if it doesn't call "super" in that method (or re-implement
the same code provided by the abstract class).

The reason I was asking for this is because I am a developer on this
project: http://nex3.leeweiz.net/posts/3 (we don't have a website yet).

Each "thing" on the canvas like a rectangle, circle, line, curve, etc is
a "Drawable" (the abstract class). Each Drawable has a state but doesn't
actually appear until its "draw" method is called. Each Drawable also
has a clone of the "brush" when it was created. This is how it knows
what fill/stroke colour etc. to use.

Basically, in order to draw a Drawable, the Drawable's brush must also
be drawn. Every single Drawable does this so the abstract class has the
code for Drawing the brush, and the concrete classes call "super" to
make this happen. If super were not called the Drawable wouldn't draw
correctly and the code would be broken.

I guess I envisaged something like

@foo.expects(:super).with(bla)

Maybe this isn't a problem for Mocha though. It occurred to me that this
kinda thing is a perfect use for RSpec's it_should_behave_like, which
could test the brush painting whilst preventing duplication of code. As
a bonus, it_should_behave_like would (correctly) let the test pass if
"super" wasn't called, but the superclass' code was re-implemented.

Jon

-- 
Jonathan Leighton, Web Developer
http://jonathanleighton.com/


From jamesmead44 at gmail.com  Wed Jul  4 14:45:18 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 4 Jul 2007 19:45:18 +0100
Subject: [mocha-developer] Fwd: [ mocha-Bugs-11885 ] never doesn't work with
	stub_everything
In-Reply-To: <20070630133307.D93BE52409B7@rubyforge.org>
References: <20070630133307.D93BE52409B7@rubyforge.org>
Message-ID: <1db558f00707041145w70844e92kd5acd7f82887edf5@mail.gmail.com>

---------- Forwarded message ----------
From: noreply at rubyforge.org <noreply at rubyforge.org>
Date: 30-Jun-2007 14:33
Subject: [ mocha-Bugs-11885 ] never doesn't work with stub_everything
To: noreply at rubyforge.org


Bugs item #11885, was opened at 2007-06-27 14:13
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=7477&aid=11885&group_id=1917

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Alexander Lang (langalex)
Assigned to: Nobody (None)
Summary: never doesn't work with stub_everything

Initial Comment:
running the following results in a succesful test with mocha 0.5.1 -
it should fail because x is called on o.



require 'rubygems'

require 'test/unit'

require 'mocha'





class MyTest < Test::Unit::TestCase

  def test_never

    o = stub_everything

    o.expects(:x).never

    o.x

  end

end

----------------------------------------------------------------------

>Comment By: James Mead (jamesmead)
Date: 2007-06-30 13:33

Message:
You are quite right. Thanks for the bug report. In fact there are a
few issues related to this. I need to have a bit of a think about
it...

----------------------------------------------------------------------

You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=7477&aid=11885&group_id=1917


-- 
James.
http://blog.floehopper.org

From jamesmead44 at gmail.com  Wed Jul  4 14:45:53 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 4 Jul 2007 19:45:53 +0100
Subject: [mocha-developer] Fwd: [ mocha-Bugs-12001 ] Method call count is
	not reported correctly on error
In-Reply-To: <20070704182112.C7B745240BAD@rubyforge.org>
References: <20070704182112.C7B745240BAD@rubyforge.org>
Message-ID: <1db558f00707041145m613fc860g790996669bd9ae30@mail.gmail.com>

---------- Forwarded message ----------
From: noreply at rubyforge.org <noreply at rubyforge.org>
Date: 04-Jul-2007 19:21
Subject: [ mocha-Bugs-12001 ] Method call count is not reported
correctly on error
To: noreply at rubyforge.org


Bugs item #12001, was opened at 2007-07-04 15:21
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=7477&aid=12001&group_id=1917

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Romulo A. Ceccon (romuloceccon)
Assigned to: Nobody (None)
Summary: Method call count is not reported correctly on error

Initial Comment:
Given a file containing the following:



  require 'test/unit'

  require 'mocha'



  class TestMocha < Test::Unit::TestCase

    def test_expectation_count

      m = mock

      m.expects(:test)



      m.test

      m.test  # fails

    end

  end



mocha fails on the second call to 'm.test' with the message:



  #<Mock:0x2e7c280>.test() - expected calls: 0, actual calls: 1

  Similar expectations:

  test



I would expect mocha to say "expected calls: 1, actual calls: 2", though.



----------------------------------------------------------------------

You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=7477&aid=12001&group_id=1917


-- 
James.
http://blog.floehopper.org

From jamesmead44 at gmail.com  Fri Jul  6 04:51:36 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Fri, 6 Jul 2007 09:51:36 +0100
Subject: [mocha-developer] advice on new failures with 0.5.0
In-Reply-To: <1db558f00706130953q62822a21q6cf704e36d32dbc6@mail.gmail.com>
References: <BCEE26D4-128E-49B7-A766-6B4250A352AA@spiceworks.com>
	<1db558f00706121132g545261a1l4676eb4561e6663f@mail.gmail.com>
	<047B0091-6E32-4248-ABEF-CBB4A5FD952D@spiceworks.com>
	<1db558f00706130953q62822a21q6cf704e36d32dbc6@mail.gmail.com>
Message-ID: <1db558f00707060151k53d67e7es10dbd8231ae9a623@mail.gmail.com>

I've finally updated the release notes in the latest release
(http://mocha.rubyforge.org/files/RELEASE.html).
-- 
James.
http://blog.floehopper.org

From laurent.francioli at gmail.com  Mon Jul  9 04:27:55 2007
From: laurent.francioli at gmail.com (Laurent Francioli)
Date: Mon, 9 Jul 2007 10:27:55 +0200
Subject: [mocha-developer] Problem with Mocks: "random" tests failing
Message-ID: <bc3742c90707090127y1eafd692n6782f9f8dfd15ee@mail.gmail.com>

Hi all!

I am pretty new to Mocha and I am writing tests that use Mocks quite a bit.
I am having a weird behavior with some of the tests for a specific class:

I wrote a first couple of tests that were passing and then when adding a 3rd
one, the first tests begun to fail. Now what's bugging me even more is that
if I run them in debugger mode with breakpoints on the functions where the
errors are, they either pass or fail on other expectations.

A few more interesting things are:
- These tests all use pretty much the same functions
- The class under test launches threads and some of the expectations are
within the threads
- Only expectations fail like this (all assert always pass)
- Commenting "random" lines (like removing an expect on no errors should be
logged) can change the outcome of the tests

So it looks like either I'm not doing the proper setup/teardown actions or
the threads are posing a problem. In my setup I always reload (require) all
the libraries I need, and create fresh objects. In the teardown I get rid of
the objects under test.

I am using the mocha gem 0.5.1 and these problems are really driving me
craaaaazy!

Please let me know if you ohave any hints for me! I'll be happy to give more
information if required.

Thanks alot,
Laurent

From dchelimsky at gmail.com  Mon Jul  9 11:21:05 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 9 Jul 2007 10:21:05 -0500
Subject: [mocha-developer] Problem with Mocks: "random" tests failing
In-Reply-To: <bc3742c90707090127y1eafd692n6782f9f8dfd15ee@mail.gmail.com>
References: <bc3742c90707090127y1eafd692n6782f9f8dfd15ee@mail.gmail.com>
Message-ID: <57c63afe0707090821q5ee06494k5cfe971ecbb54614@mail.gmail.com>

On 7/9/07, Laurent Francioli <laurent.francioli at gmail.com> wrote:
> Hi all!
>
> I am pretty new to Mocha and I am writing tests that use Mocks quite a bit.
> I am having a weird behavior with some of the tests for a specific class:
>
> I wrote a first couple of tests that were passing and then when adding a 3rd
> one, the first tests begun to fail. Now what's bugging me even more is that
> if I run them in debugger mode with breakpoints on the functions where the
> errors are, they either pass or fail on other expectations.
>
> A few more interesting things are:
> - These tests all use pretty much the same functions
> - The class under test launches threads and some of the expectations are
> within the threads
> - Only expectations fail like this (all assert always pass)
> - Commenting "random" lines (like removing an expect on no errors should be
> logged) can change the outcome of the tests
>
> So it looks like either I'm not doing the proper setup/teardown actions or
> the threads are posing a problem. In my setup I always reload (require) all
> the libraries I need, and create fresh objects. In the teardown I get rid of
> the objects under test.
>
> I am using the mocha gem 0.5.1 and these problems are really driving me
> craaaaazy!
>
> Please let me know if you ohave any hints for me! I'll be happy to give more
> information if required.

I think we'd really need specific examples to be able to help you. Is
it possible for you to post the code? Both the test code and the code
being tested would be most helpful.

>
> Thanks alot,
> Laurent
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From jamesmead44 at gmail.com  Tue Jul 10 05:38:49 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 10 Jul 2007 10:38:49 +0100
Subject: [mocha-developer] Problem with Mocks: "random" tests failing
In-Reply-To: <57c63afe0707090821q5ee06494k5cfe971ecbb54614@mail.gmail.com>
References: <bc3742c90707090127y1eafd692n6782f9f8dfd15ee@mail.gmail.com>
	<57c63afe0707090821q5ee06494k5cfe971ecbb54614@mail.gmail.com>
Message-ID: <1db558f00707100238s18ccd2ceo514c9745557aa2d2@mail.gmail.com>

I suspect this is due to the fact that exceptions raised in one thread
are not caught in another. Mocha was not designed to test across
multiple threads. In general it is not a good idea to do
multi-threaded unit testing.

You need to separate out the multi-threaded concern of the code so you
can unit test the logic in a single thread. There is an excellent
article on the JMock site (http://www.jmock.org/threads.html) that
should explain this better - don't be put off by the fact the examples
are in Java - they are very readable.

If you are still stuck - perhaps you can do as David suggests and send
us a chunk of sample code that you are having difficulty testing.
-- 
James.
http://blog.floehopper.org

From j at jonathanleighton.com  Mon Jul 16 17:39:09 2007
From: j at jonathanleighton.com (Jonathan Leighton)
Date: Mon, 16 Jul 2007 22:39:09 +0100
Subject: [mocha-developer] Set the return value to "same as block"
Message-ID: <1184621949.14140.11.camel@localhost.localdomain>

It would be good to be able to set the return value to be the same as
the return value of the block. I am trying to test opening a file in a
block and reading from it. It would be nice to use code like this:

object.stubs(:open).with("/path/to/file", "r").yields(
  stub(:read => "The file contents")
).returns(from_block)

Which would make open() take the return value of the block. So this app
code would work:

def my_method
  open("/path/to/file", "r") { |file| file.read }
end

and this wouldn't work (because the return value of the block is not the
contents of the file):

def my_method
  open("/path/to/file", "r") do |file|
    file.read
    puts "Stolid in my guilt, clutching it like a girl with a stuffed
bunny, I failed to follow."
  end
end

-- 
Jonathan Leighton, Web Developer
http://jonathanleighton.com/


From jamesmead44 at gmail.com  Wed Jul 18 04:45:54 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 18 Jul 2007 09:45:54 +0100
Subject: [mocha-developer] Set the return value to "same as block"
In-Reply-To: <1184621949.14140.11.camel@localhost.localdomain>
References: <1184621949.14140.11.camel@localhost.localdomain>
Message-ID: <1db558f00707180145h297bd655jff7212cb26dca4a1@mail.gmail.com>

I'm a bit confused as to what you are trying to test - there are no expects
or asserts in your examples. Can you give a simple but complete example with
both test and code. In particular, are you trying to test the functionality
of the method or the block?
-- 
James.
http://blog.floehopper.org

From johnwilger at gmail.com  Wed Jul 18 14:21:36 2007
From: johnwilger at gmail.com (John Wilger)
Date: Wed, 18 Jul 2007 11:21:36 -0700
Subject: [mocha-developer] Set the return value to "same as block"
In-Reply-To: <1db558f00707180145h297bd655jff7212cb26dca4a1@mail.gmail.com>
References: <1184621949.14140.11.camel@localhost.localdomain>
	<1db558f00707180145h297bd655jff7212cb26dca4a1@mail.gmail.com>
Message-ID: <a05e51b60707181121l5ccf59edk314e96d9b77f6ed3@mail.gmail.com>

On 7/18/07, James Mead <jamesmead44 at gmail.com> wrote:
> I'm a bit confused as to what you are trying to test - there are no expects
> or asserts in your examples. Can you give a simple but complete example with
> both test and code. In particular, are you trying to test the functionality
> of the method or the block?

I think he's trying to test the following type of thing (at least,
this is how I read it):

# test case method
def test_should_offset_each_char_by_one_position
  scrambler = Scrambler.new
  File.expects( :open ).with( '/abc.txt', 'r' ).yields( stub( :read => 'abc' ) )
  assert_equal 'bca', scrambler.offset_read( 'abc.txt' )
end

# Scrambler method
def offset_read( path )
  File.open( path, 'r' ) do |f|
    chars = file.read.to_a
    ( chars << chars.shift ).to_s
  end
end

In other words, if you have an expectation which uses #yields, rather
than having to explicitly define the return value, is it possible to
have it return the result of the block that was yielded to? Maybe this
already works -- I haven't tried.

-- 
Regards,
John Wilger
http://johnwilger.com

-----------
"Quality means doing it right when no one is looking." ? Henry Ford

From jamesmead at reevoo.com  Sat Jul 21 16:21:12 2007
From: jamesmead at reevoo.com (James Mead)
Date: Sat, 21 Jul 2007 21:21:12 +0100
Subject: [mocha-developer] Mocha featured on Railscasts
In-Reply-To: <e8a8e9570707210120s5d4fb6d6k3cfde5ea6459fb72@mail.gmail.com>
References: <e8a8e9570707210120s5d4fb6d6k3cfde5ea6459fb72@mail.gmail.com>
Message-ID: <548F02AD-716D-441E-95C3-75BE6122FEBB@reevoo.com>

Cool. Thanks for letting me know.

On 21 Jul 2007, at 09:20, Chris O'Sullivan wrote:

> Heya James,
>
> I thought you'd like to know that Mocha featured in the latest  
> Railscasts.
>
> Check it out here: http://railscasts.com/episodes/60
>
> -Chris
>


From jamesmead at reevoo.com  Sat Jul 21 16:22:20 2007
From: jamesmead at reevoo.com (James Mead)
Date: Sat, 21 Jul 2007 21:22:20 +0100
Subject: [mocha-developer] Fwd: Tagging Mocha 0.5.x
References: <4FA410E2-DBE1-4CC0-9BD3-E9684C620C71@mail.com>
Message-ID: <9D121125-D4A0-4524-B8A3-89AEF05E1AC2@reevoo.com>

Mocha 0.5.2 now tagged in svn repos.

Begin forwarded message:

> From: James Mead <james.mead at mail.com>
> Date: 21 July 2007 10:21:11 BDT
> To: Zach Dennis <zach.dennis at gmail.com>
> Subject: Re: Tagging Mocha 0.5.x
>
> Hi Zach,
>
> Thanks for pointing that out. I've just tagged 0.5.2 and will try  
> to retrofit earlier tags as soon as I can.
>
> James.
>
> On 20 Jul 2007, at 21:11, Zach Dennis wrote:
>
>> James,
>>
>> Can you tag svn with your Mocha releases? It's difficult to have  
>> svn externals or a piston import of your Mocha 0.5.2 when it's not  
>> tagged.
>>
>> Thanks,
>>
>> Zach
>


From j at jonathanleighton.com  Sun Jul 22 11:26:20 2007
From: j at jonathanleighton.com (Jonathan Leighton)
Date: Sun, 22 Jul 2007 16:26:20 +0100
Subject: [mocha-developer] Set the return value to "same as block"
In-Reply-To: <1db558f00707180145h297bd655jff7212cb26dca4a1@mail.gmail.com>
References: <1184621949.14140.11.camel@localhost.localdomain>
	<1db558f00707180145h297bd655jff7212cb26dca4a1@mail.gmail.com>
Message-ID: <1185117980.6550.4.camel@localhost.localdomain>

On Wed, 2007-07-18 at 09:45 +0100, James Mead wrote:
> I'm a bit confused as to what you are trying to test - there are no expects
> or asserts in your examples. Can you give a simple but complete example with
> both test and code. In particular, are you trying to test the functionality
> of the method or the block?

Basically, I am trying to test that my_method returns the contents of
the file. The Kernel#open method will return what its block returns, so
when stubbing Kernel#open I am trying to simulate this behaviour. The
assertion would be (sorry I missed this out):

assert_equal "The file contents", obj.my_method

Here's a complete example:

require 'test/unit'

class Foo
  def return_from_block
    return yield
  end
  
  def my_method
    return_from_block { "Something" }
  end
end

class FooTest < Test::Unit::Testcase
  def test_my_method
    foo = Foo.new
    foo.stubs(:return_from_block).returns(from_block)
    
    assert_equal "Something", foo.my_method
  end
end

-- 
Jonathan Leighton, Web Developer
http://jonathanleighton.com/


From jamesmead44 at gmail.com  Sun Jul 22 13:12:36 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Sun, 22 Jul 2007 18:12:36 +0100
Subject: [mocha-developer] Set the return value to "same as block"
In-Reply-To: <1185117980.6550.4.camel@localhost.localdomain>
References: <1184621949.14140.11.camel@localhost.localdomain>
	<1db558f00707180145h297bd655jff7212cb26dca4a1@mail.gmail.com>
	<1185117980.6550.4.camel@localhost.localdomain>
Message-ID: <1db558f00707221012r70f46a45n2583ec13201aa205@mail.gmail.com>

Thanks for taking the time to explain more fully. We know that there are
shortcomings in Mocha regarding blocks.

It looks to me like you are trying to find a way to indirectly test the code
in the block.

While I can see how your solution works in some cases, I'm not sure it is a
generic solution e.g. what if a method accepts multiple blocks or what if
the result of the block is not normally returned by the method being mocked.

One thing I've been planning on doing for a while is to provide a way to use
a new parameter matcher that can check for a block being passed to a mocked
method. I think it would have to work by comparing an expected result with
the result of executing the block.

I have to admit to being a bit undecided about all of this. I think one
thing I need to do is to write up a series of scenarios that we need to
handle.

Let me know if I've misunderstood or if you've got any other ideas how to
make the handling of blocks more straightforward.

-- 
James.
http://blog.floehopper.org

From cwdinfo at gmail.com  Sun Jul 22 19:46:20 2007
From: cwdinfo at gmail.com (s.ross)
Date: Sun, 22 Jul 2007 16:46:20 -0700
Subject: [mocha-developer] Stubbing Constants
In-Reply-To: <1db558f00706081411p5633b8e5t7fcfff4747fe5698@mail.gmail.com>
References: <1db558f00706081411p5633b8e5t7fcfff4747fe5698@mail.gmail.com>
Message-ID: <6FB15EFD-E1D0-4B95-B600-27122ADF3584@gmail.com>

This may sound odd, but here's the scenario: My Rails app behaves a  
bit differently in development versus production mode. Because Ruby  
won't let me redefine constants like RAILS_ENV I thought, hmmmmmmmm,  
maybe I can just stub it and then write tests that were mode specific.

Is this something that can be done with Mocha?

Thanks

From jamesmead44 at gmail.com  Mon Jul 23 04:21:16 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Mon, 23 Jul 2007 09:21:16 +0100
Subject: [mocha-developer] Stubbing Constants
In-Reply-To: <6FB15EFD-E1D0-4B95-B600-27122ADF3584@gmail.com>
References: <1db558f00706081411p5633b8e5t7fcfff4747fe5698@mail.gmail.com>
	<6FB15EFD-E1D0-4B95-B600-27122ADF3584@gmail.com>
Message-ID: <1db558f00707230121x5fa72805k63a3f529cfe531bb@mail.gmail.com>

On 23/07/07, s.ross <cwdinfo at gmail.com> wrote:
>
> This may sound odd, but here's the scenario: My Rails app behaves a
> bit differently in development versus production mode. Because Ruby
> won't let me redefine constants like RAILS_ENV I thought, hmmmmmmmm,
> maybe I can just stub it and then write tests that were mode specific.
>
> Is this something that can be done with Mocha?


No. Not currently.

I suggest you use Module#const_set for your tests and make sure you reset at
the end of the test OR setup a new environment which mirrors your
production.rb file in which you can run tests.

-- 
James.
http://blog.floehopper.org

From cwdinfo at gmail.com  Mon Jul 23 11:50:23 2007
From: cwdinfo at gmail.com (s.ross)
Date: Mon, 23 Jul 2007 08:50:23 -0700
Subject: [mocha-developer] Stubbing Constants
In-Reply-To: <1db558f00707230121x5fa72805k63a3f529cfe531bb@mail.gmail.com>
References: <1db558f00706081411p5633b8e5t7fcfff4747fe5698@mail.gmail.com>
	<6FB15EFD-E1D0-4B95-B600-27122ADF3584@gmail.com>
	<1db558f00707230121x5fa72805k63a3f529cfe531bb@mail.gmail.com>
Message-ID: <C9B618CD-483C-4F44-A013-62DF0546E028@gmail.com>

I wound up using:

class Module
   def redefine_const(name, value)
     __send__(:remove_const, name) if const_defined?(name)
     const_set(name, value)
   end
end

The changing the constant on Object:

Object.redefine_const(:RAILS_ENV, 'production')

This fights with Mocha, but accomplishes my goal.

Thanks

On Jul 23, 2007, at 1:21 AM, James Mead wrote:

> On 23/07/07, s.ross <cwdinfo at gmail.com> wrote:
>>
>> This may sound odd, but here's the scenario: My Rails app behaves a
>> bit differently in development versus production mode. Because Ruby
>> won't let me redefine constants like RAILS_ENV I thought, hmmmmmmmm,
>> maybe I can just stub it and then write tests that were mode  
>> specific.
>>
>> Is this something that can be done with Mocha?
>
>
> No. Not currently.
>
> I suggest you use Module#const_set for your tests and make sure you  
> reset at
> the end of the test OR setup a new environment which mirrors your
> production.rb file in which you can run tests.
>
> -- 
> James.
> http://blog.floehopper.org
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer


From jamesmead44 at gmail.com  Tue Jul 24 03:04:43 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 24 Jul 2007 08:04:43 +0100
Subject: [mocha-developer] Fwd: *.rubyforge.org sites disappearing from
	google?
In-Reply-To: <6c8693640707232027u5fda810rd08f824636a2f63e@mail.gmail.com>
References: <6c8693640707232027u5fda810rd08f824636a2f63e@mail.gmail.com>
Message-ID: <1db558f00707240004n8d3e8c2gdaf7b62033aafa38@mail.gmail.com>

---------- Forwarded message ----------
From: Leonard Chin <l.g.chin at gmail.com>
Date: 24-Jul-2007 04:26
Subject: *.rubyforge.org sites disappearing from google?
To: ruby-talk ML <ruby-talk at ruby-lang.org>

Has anyone noticed that projects with homepages hosted on rubyforge
have disappeared from the google index? When trying to google rspec,
mongrel, mocha, fastercsv, their respective *.rubyforge.org pages fail
to appear in the search results.

This may be just a temporary hiccup, however...



-- 
James.
http://blog.floehopper.org

From jamesmead44 at gmail.com  Tue Jul 24 03:40:17 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 24 Jul 2007 08:40:17 +0100
Subject: [mocha-developer] community poll about testing and specs
Message-ID: <1db558f00707240040o70c8d6f7xeb01dc4855eb7ecb@mail.gmail.com>

I thought people on this list might be interested in voicing an opinion on
this thread...

http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/4c378d9417a03ac

-- 
James.
http://blog.floehopper.org

From jamesmead at reevoo.com  Tue Jul 24 15:54:01 2007
From: jamesmead at reevoo.com (James Mead)
Date: Tue, 24 Jul 2007 20:54:01 +0100
Subject: [mocha-developer] mocha tarballs don't uncompress cleanly
In-Reply-To: <20070724194204.GA10703@softwarelivre.org>
References: <20070724194204.GA10703@softwarelivre.org>
Message-ID: <C0A4B09B-B440-4586-8793-19DA2E4CC762@reevoo.com>

Hi Antonio,

My environment is OS X 10.4.8.

Thanks a lot for looking into the problem. Please let me know if I  
can do anything to help.

I have had problems previously with tar including Mac resource fork  
files. Could this be what is causing your problem?

James.

On 24 Jul 2007, at 20:42, Antonio Terceiro wrote:

> Hi James,
>
> First of all, thanks for mocha, it's a really great library and helps
> testing a lot. :)
>
> I downloaded the mocha tarball for versions 0.5.0, 0.5.1 and 0.5.2
> (didn't test older ones), and when uncompressing all of them I get the
> following error:
>
> -------------------8<---------------------8<-----------------------
> terceiro at s219pc02:/tmp/bli$ LANG=C tar xzf ../mocha-0.5.2.tgz
>
> gzip: stdin: decompression OK, trailing garbage ignored
> tar: Child returned status 2
> tar: Error exit delayed from previous errors
> -------------------8<---------------------8<-----------------------
>
> The tarball is uncompressed, but this error message (and the non-zero
> exit status) is pretty annoying.
>
> I tried to reproduce the tarball generation here on my machine, by
> entering the mocha-0.5.2 directory and issuing a `rake package`  
> command,
> but the generated tarball is uncompressed cleanly. According to the
> message, the problem seems to be in the gzip compression, but I can't
> actually tell what is causing it.
>
> Can you please tell me which environment you are used to generate the
> mocha packages on, so I can try to prepare a fix to this issue?
>
> Best regards,
>
> -- 
> Antonio Terceiro <terceiro at softwarelivre.org>
> http://people.softwarelivre.org/~terceiro/
> GnuPG ID: 0F9CB28F
>
>
>


From jamesmead at reevoo.com  Wed Jul 25 10:56:14 2007
From: jamesmead at reevoo.com (James Mead)
Date: Wed, 25 Jul 2007 15:56:14 +0100
Subject: [mocha-developer] mocha tarballs don't uncompress cleanly
In-Reply-To: <20070725134425.GB26200@softwarelivre.org>
References: <20070724194204.GA10703@softwarelivre.org>
	<C0A4B09B-B440-4586-8793-19DA2E4CC762@reevoo.com>
	<20070725134425.GB26200@softwarelivre.org>
Message-ID: <AD982887-64BD-41C0-AA91-0EF6117D58AB@reevoo.com>

Many thanks again for looking into this. Here are the answers to your  
questions...

On 25 Jul 2007, at 14:44, Antonio Terceiro wrote:

> What's the versions of gzip and tar in your system? Here I have  
> gzip 1.3.5
> and tar 1.16 ...

$ tar --version
tar (GNU tar) 1.14

$ gzip --version
gzip 1.3.5

$ gunzip --version
gunzip 1.3.5

> Could you send me the output of the `rake package` there?

?

> What happens if you try to uncompress the generated tarball?

?

From zach.lists at gmail.com  Wed Jul 25 23:52:07 2007
From: zach.lists at gmail.com (Zach Moazeni)
Date: Wed, 25 Jul 2007 23:52:07 -0400
Subject: [mocha-developer] Test errors without verification
Message-ID: <01A5846A-D377-4FB0-8BE9-1D66C5AB7508@gmail.com>

(Sorry if anyone receives duplicates, I'm not sure if the first one  
was successfully sent)

I'm not sure if this is by design, but I've stumbled across this a  
few times trying to debug my own tests. If an assertion fails the  
test, and a missing mock expectation was to blame, the test's  
failure / error messages don't give enough info. I've had to resort to

def teardown
   mocha_verify
end

which just gets tedious.

I've created a patch against trunk v164 and included it below.

Example:

def test_something
     mock = mock("some mock")
     mock.expects(:message)
     flunk # or fail
end

I'm expecting to get both the flunk / fail message AND the Mocha  
expectation failure.

It's a very minor change, but I'm interested in what you guys think,

-Zach


-------------- next part --------------


From jamesmead44 at gmail.com  Thu Jul 26 05:12:56 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Thu, 26 Jul 2007 10:12:56 +0100
Subject: [mocha-developer] Test errors without verification
In-Reply-To: <01A5846A-D377-4FB0-8BE9-1D66C5AB7508@gmail.com>
References: <01A5846A-D377-4FB0-8BE9-1D66C5AB7508@gmail.com>
Message-ID: <1db558f00707260212t4a1d49cl924a4c4e39ea0fb3@mail.gmail.com>

Hi Zach,

On 26/07/07, Zach Moazeni <zach.lists at gmail.com> wrote:
>
> I'm not sure if this is by design, but I've stumbled across this a
> few times trying to debug my own tests. If an assertion fails the
> test, and a missing mock expectation was to blame, the test's
> failure / error messages don't give enough info.


This is by design. In my mind a verification failure is analogous to an
assertion failure. Test::Unit does not report multiple assertion failures
per test, but reports the first failure. Failing fast seems like the right
thing to do. At that point all bets are off and there is no point in
continuing.

I wonder if the pain you are feeling is because you have too many assertions
and/or expectations in each test. You might find the following article
interesting...

http://blog.jayfields.com/2007/06/testing-one-assertion-per-test.html

Thanks for taking the time to put a patch together, but at this stage I'm
not convinced it's the way to go.

-- 
James.
http://blog.floehopper.org

From zach at elevatorup.com  Wed Jul 25 23:49:02 2007
From: zach at elevatorup.com (Zach Moazeni)
Date: Wed, 25 Jul 2007 23:49:02 -0400
Subject: [mocha-developer] Test errors without verification
Message-ID: <96A5A124-495A-4C20-9648-1827B1F43441@elevatorup.com>

I'm not sure if this is by design, but I've stumbled across this a  
few times trying to debug my own tests. If an assertion fails the  
test, and a mock expectation was to blame, the test's failure / error  
messages don't give enough info. I've had to resort to

def teardown
   mocha_verify
end

which just gets tedious.

I've created a patch against trunk v164 and included it below.

Example:

def test_something
     mock = mock("some mock")
     mock.expects(:message)
     flunk # or fail
end

I'm expecting to get both the flunk / fail message AND the Mocha  
expectation failure.

It's a very minor change, but I'm interested in what you guys think,

-Zach


From zach.lists at gmail.com  Thu Jul 26 07:20:48 2007
From: zach.lists at gmail.com (Zach Moazeni)
Date: Thu, 26 Jul 2007 07:20:48 -0400
Subject: [mocha-developer] Test errors without verification
In-Reply-To: <1db558f00707260212t4a1d49cl924a4c4e39ea0fb3@mail.gmail.com>
References: <01A5846A-D377-4FB0-8BE9-1D66C5AB7508@gmail.com>
	<1db558f00707260212t4a1d49cl924a4c4e39ea0fb3@mail.gmail.com>
Message-ID: <32498AF4-E733-4619-A319-46F741A14462@gmail.com>

James,

That's an interesting article. I haven't come across that, but I do  
something very similar when testing validations in ActiveRecord. The  
problems I encounter more often are testing an object in isolation  
where I'll have a scenario similar to the following.

class Car
   def intialize(engine)
     @parts = []
     @parts << engine\
   end

   def start
     # run though a ton of part and return whether the car started
     # typically there would be error handling, or you would just AND  
all the parts.start
     started = false
     @parts.each do | part |
        started = started && part.start
     end

     started
   end
end

def test_start_the_car
   engine_mock = mock("engine")
   car = Car.new(engine_mock)

   engine_mock.expects(:start).returns(true)
   assert car.start
end

This is a trivial example I just made up of the top of my head, but  
you can imagine if the code at Car#start did not call Engine#start,  
and that resulted in the assertion failure. The test does not give as  
much feedback as it could to help the developer determine what went  
wrong.

In my opinion its quicker to debug if both errors / failures are  
reported and you have a little more to go off on rather than having  
to dig into the code / tests immediately to try and locate where the  
point of failure occurred.

If you'd still rather the designed behavior, would it be possible to  
propose an alternate patch that looks similar to the following

class VerboseFailuresTest < Test::Unit::TestCase

   mocha_force_verifications = true

   def test_foo
      ...
   end
end

which has the default behavior of false (to accommodate the original  
design)?

-Zach

On Jul 26, 2007, at 5:12 AM, James Mead wrote:

> Hi Zach,
>
> On 26/07/07, Zach Moazeni <zach.lists at gmail.com> wrote:
>>
>> I'm not sure if this is by design, but I've stumbled across this a
>> few times trying to debug my own tests. If an assertion fails the
>> test, and a missing mock expectation was to blame, the test's
>> failure / error messages don't give enough info.
>
>
> This is by design. In my mind a verification failure is analogous  
> to an
> assertion failure. Test::Unit does not report multiple assertion  
> failures
> per test, but reports the first failure. Failing fast seems like  
> the right
> thing to do. At that point all bets are off and there is no point in
> continuing.
>
> I wonder if the pain you are feeling is because you have too many  
> assertions
> and/or expectations in each test. You might find the following article
> interesting...
>
> http://blog.jayfields.com/2007/06/testing-one-assertion-per-test.html
>
> Thanks for taking the time to put a patch together, but at this  
> stage I'm
> not convinced it's the way to go.
>
> -- 
> James.
> http://blog.floehopper.org
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer


From zach.lists at gmail.com  Thu Jul 26 08:41:22 2007
From: zach.lists at gmail.com (Zach Moazeni)
Date: Thu, 26 Jul 2007 08:41:22 -0400
Subject: [mocha-developer] Test errors without verification
In-Reply-To: <1db558f00707260212t4a1d49cl924a4c4e39ea0fb3@mail.gmail.com>
References: <01A5846A-D377-4FB0-8BE9-1D66C5AB7508@gmail.com>
	<1db558f00707260212t4a1d49cl924a4c4e39ea0fb3@mail.gmail.com>
Message-ID: <F8614D97-F5A3-43AE-85D4-FB7783909483@gmail.com>

James,

That's an interesting article. I haven't come across that, but I do  
something very similar when testing validations in ActiveRecord. The  
problems I encounter more often are testing an object in isolation  
where I'll have a scenario similar to the following.

class Car
   def intialize(engine)
     @parts = []
     @parts << engine\
   end

   def start
     # run though a ton of part and return whether the car started
     # typically there would be error handling, or you would just AND  
all the parts.start
     started = false
     @parts.each do | part |
        started = started && part.start
     end

     started
   end
end

def test_start_the_car
   engine_mock = mock("engine")
   car = Car.new(engine_mock)

   engine_mock.expects(:start).returns(true)
   assert car.start
end

This is a trivial example I just made up of the top of my head, but  
you can imagine if the code at Car#start did not call Engine#start,  
and that resulted in the assertion failure. The test does not give as  
much feedback as it could to help the developer determine what went  
wrong.

In my opinion its quicker to debug if both errors / failures are  
reported and you have a little more to go off on rather than having  
to dig into the code / tests immediately to try and locate where the  
point of failure occurred.

If you'd still rather the designed behavior, would it be possible to  
propose an alternate patch that looks similar to the following

class VerboseFailuresTest < Test::Unit::TestCase

   mocha_force_verifications = true

   def test_foo
      ...
   end
end

which has the default behavior of false (to accommodate the original  
design)?

-Zach

On Jul 26, 2007, at 5:12 AM, James Mead wrote:

> Hi Zach,
>
> On 26/07/07, Zach Moazeni <zach.lists at gmail.com> wrote:
>>
>> I'm not sure if this is by design, but I've stumbled across this a
>> few times trying to debug my own tests. If an assertion fails the
>> test, and a missing mock expectation was to blame, the test's
>> failure / error messages don't give enough info.
>
>
> This is by design. In my mind a verification failure is analogous  
> to an
> assertion failure. Test::Unit does not report multiple assertion  
> failures
> per test, but reports the first failure. Failing fast seems like  
> the right
> thing to do. At that point all bets are off and there is no point in
> continuing.
>
> I wonder if the pain you are feeling is because you have too many  
> assertions
> and/or expectations in each test. You might find the following article
> interesting...
>
> http://blog.jayfields.com/2007/06/testing-one-assertion-per-test.html
>
> Thanks for taking the time to put a patch together, but at this  
> stage I'm
> not convinced it's the way to go.
>
> -- 
> James.
> http://blog.floehopper.org
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer


From jamesmead at reevoo.com  Sat Jul 28 18:58:27 2007
From: jamesmead at reevoo.com (James Mead)
Date: Sat, 28 Jul 2007 23:58:27 +0100
Subject: [mocha-developer] mocha tarballs don't uncompress cleanly
In-Reply-To: <20070727131256.GA5587@softwarelivre.org>
References: <20070724194204.GA10703@softwarelivre.org>
	<C0A4B09B-B440-4586-8793-19DA2E4CC762@reevoo.com>
	<20070725134425.GB26200@softwarelivre.org>
	<AD982887-64BD-41C0-AA91-0EF6117D58AB@reevoo.com>
	<20070725154130.GC5713@softwarelivre.org>
	<764E4F63-5F75-4420-A12F-1490BF269126@reevoo.com>
	<20070725172853.GA13035@softwarelivre.org>
	<525B9717-4C07-49BE-976B-56AAB8B1DFD4@reevoo.com>
	<20070727131256.GA5587@softwarelivre.org>
Message-ID: <3446B288-9F34-4B87-975A-E005B4B5F4F2@reevoo.com>

I've just released a new version of Mocha (0.5.3).

I've attempted to fix the packaging problems by switching to newer  
version (1.15.1) of gnutar and setting  
COPY_EXTENDED_ATTRIBUTES_DISABLE environment variable in my OSX bash  
environment. This seems to have got rid of the pesky ._*.rb files.

Let me know if you are still having the same problem unpacking the  
new versions of the files.

Thanks.

On 27 Jul 2007, at 14:12, Antonio Terceiro wrote:

> James Mead escreveu isso a?:
>>
>> On 25 Jul 2007, at 18:28, Antonio Terceiro wrote:
>>> This one uncompresses cleanly. I suspect that maybe there can be a
>>> problem
>>> with that Rake task which uploads the file to rubyforge ...
>>>
>>> It's very unlikely, but would you still have the exact tarball you
>>> generated just before an upload to rubyforge? I guess any version
>>> would
>>> be good enough.
>>
>> Sorry. I overwrote it when I created the one I sent you.
>
> Ahh, damn ... :)
>
>> Perhaps I should try re-publishing to rubyforge. I'll try and do it
>> over the weekend.
>
> Ok, feel free to ping me then.
>
> Creers,
>
> -- 
> Antonio Terceiro <terceiro at softwarelivre.org>
> http://people.softwarelivre.org/~terceiro/
> GnuPG ID: 0F9CB28F
>
>
>


From jonathan.stott at gmail.com  Mon Jul 30 10:15:47 2007
From: jonathan.stott at gmail.com (Jonathan Stott)
Date: Mon, 30 Jul 2007 15:15:47 +0100
Subject: [mocha-developer] Object.stubs doesn't seem to work.
Message-ID: <14cf210a0707300715i49a9f04dw4f716593e66e663b@mail.gmail.com>

Hi

I'm using Mocha 0.5.3 and I want to stub out a call to Time.now, just
like the example in the post
http://blog.floehopper.org/articles/2007/06/08/mocha-0-5-released

However, trying it in irb gets me the following error:

>> require 'mocha'
=> true
>> Time.stubs(:now).returns(Time.parse('Thu Feb 01 00:00:00 UTC 2007'))
NoMethodError: undefined method `stub' for nil:NilClass
        from /usr/lib/ruby/gems/1.8/gems/mocha-0.5.3/lib/mocha/object.rb:57:in
`stubs'
        from (irb):2

Has this way of stubbing been depreciated between 0.5.0 and 0.5.3, and
if so, what is the new way of stubbing for an Object.method ?

Regards
Jonathan

From jamesmead44 at gmail.com  Mon Jul 30 10:27:09 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Mon, 30 Jul 2007 15:27:09 +0100
Subject: [mocha-developer] Object.stubs doesn't seem to work.
In-Reply-To: <14cf210a0707300715i49a9f04dw4f716593e66e663b@mail.gmail.com>
References: <14cf210a0707300715i49a9f04dw4f716593e66e663b@mail.gmail.com>
Message-ID: <1db558f00707300727s65483d58v273cc6e74514042a@mail.gmail.com>

Hi Jonathan,

You need to use Mocha in the context of a Test::Unit::TestCase (or an RSpec
specification).

The blog post missed this out to improve the signal-to-noise ratio.

require 'rubygems'
require 'mocha'
require 'test/unit'

class TimeTest < Test::Unit::TestCase

  def test_time_now
    Time.stubs(:now).returns(Time.parse('Thu Feb 01 00:00:00 UTC 2007'))
    assert_equal Time.parse('Thu Feb 01 00:00:00 UTC 2007'), Time.now
  end

end

The reason it needs to be within a TestCase or similar is because Mocha
temporarily modifies the Time class for the duration of the test and needs a
hook to put it back how it was.

I hope that makes sense.
-- 
James.
http://blog.floehopper.org

From jonathan.stott at gmail.com  Tue Jul 31 05:56:13 2007
From: jonathan.stott at gmail.com (Jonathan Stott)
Date: Tue, 31 Jul 2007 10:56:13 +0100
Subject: [mocha-developer]  Object.stubs doesn't seem to work.
Message-ID: <14cf210a0707310256k5ae92cc4td6d65c0223a8297b@mail.gmail.com>

Ah, yes, thank you!

I feel a little foolish now.  It hadn't occured to me it needed to be
in a TestCase when I set out to test it a little first in irb.

Thanks for the quick response
Jonathan