I- tried the pure stubbing approach as did Pete Yandell with his notamock
rails plugin - the stubs will return nil for any method call unless to tell
them to do otherwise (return something, yield something and/or raise
something).  So everything is a stub (just one that happens to be a .net
interface implementation) that records all calls for later inspection.
The null object i'll add next (the stubs will just return another stub
instead of nil and record all calls).

The assertions are then at the end of the test/spec (where I think all
expectations should be) - at this stage you need to scan the list of
recorded calls - i'll add some syntax to do nicer checking.

Does your final point suggest that the event implementation will be
available soon?

Mark.

On Sun, May 10, 2009 at 6:21 PM, Jim Deville <[email protected]> wrote:

>  1. Other features: I don't use most of the fancy features, but I do find 
> stubs useful. Do you expect people to use when_told_to without was_told_to? 
> in order to stub something out?
> 2. I also find the 'null object' pattern useful. That is where the isolated 
> object always returns nil to methods called on it.
> 3. Finally, I've been slow on pushing lately because I'm moving, I'll do a 
> push when I get to decent internet. I'll also work on automating thid in the 
> next couple of weeks.
>
>
> JD
>
> ....there is no try
> Sent from my phone. Please excuse typos and txtspk.
>
> -----Original Message-----
> From: Ivan Porto Carrero <[email protected]>
> Sent: May 10, 2009 1:11 AM
> To: [email protected] <[email protected]>
> Subject: Re: [Ironruby-core] IronRuby projects newsletter
>
>
> Yesterday I actually finished my implementation I think.  I will probably
> need to add some more matchers and expectations. I'm now documenting the
> thing, creating the gemspecs and applying to rubyforge so that I can release
> the gem on rubyforge too.
>
>  From the start I wanted to do away with names like mock, stub, record,
> replay, verify etc.  Instead I took the advice from Roy Osherhove and went
> with a name of Isolator (Isolation might be better though) for creating a
> mock.
>
>  An Isolator will create what in Rhino.Mocks would be called a
> PartialDynamicMock :)  In Moq it would be the Loose mocking strategy.
>
>  The naming of the methods for creating mocks is the one that JP Boodhoo
> proposed WhenToldTo and WasToldTo.
> To specify a stub/expectation on a mock you have one and only one way of
> doing that with the method called when_told_to.
> Then when you're asserting you can use the was_told_to method
>
>  mock = Isolator.for(Ninja)
> mock.when_told_to(:attack) do |exp|
>   exp.with(:shuriken)
>   exp.return(3)
> end
>
>  Battle.new(mock)
> battle.combat
>
>  mock.was_told_to?(:attack).should.be.successful
>
>  Caricature handles interfaces, interface inheritance, CLR objects, CLR
> object instances, Ruby classes and instances of Ruby classes.
>
>  I only embarked on this project because I really want to get IronRubyMVC
> spec'ed with a ruby testing framework, on the other hand it has been good
> fun.
>
>  So now I'm trying to find out if people actually want more from a mocking
> library than setting expectations, verifying those expectations on arguments
> and/or number of times called.
>
>  I find that when I use mocking I tend to stay away of the fancy stuff and
> that it was this fancy stuff that confused the hell out of me in the
> beginning because I needed to give it a place (which turned out to be
> oblivion :) )  Along with all the confusion that grew out of StrictMock,
> DynamicMock, PartialMock and Stub.
>
>  So if anybody is up to reviewing the code please do. I welcome all
> suggestions, issue submissions etc.
>
>  I couldn't add support for events yet and commented out the spec that
> tests that. I saw a tweet passing by from Curt where he was too tired to
> test the event support. Then downloaded the latest git but it still won't
> work. Do I need to submit a bug for that or just be a little bit more
> patient ?
>
>
>  ---
> Met vriendelijke groeten - Best regards - Salutations
> Ivan Porto Carrero
> GSM: +32.486.787.582
> Blog: http://flanders.co.nz
> Twitter: http://twitter.com/casualjim
> Author of IronRuby in Action (http://manning.com/carrero)
>
> Bernard 
> Baruch<http://www.brainyquote.com/quotes/authors/b/bernard_baruch.html> - 
> "Vote for the man who promises least; he'll be the least disappointing."
>
> On Sun, May 10, 2009 at 3:00 AM, Mark Ryall <[email protected]> wrote:
>
>> Hi everyone,
>>
>>  Ivan and I have taken the interesting approach to collaboration by each
>> working on our own subtly different mock objects implementation,
>> communicating regularly and stealing each other's ideas where necessary.
>>  I released my crude attempt yesterday in case anyone wants to play
>> around with it:
>>
>>  gem install markryall-orangutan (from gems.github.com)
>>
>>  or
>>
>>  gem install orangutan (from rubyforge)
>>
>>  At this stage, you can only create stubs that implement a clr interface
>> (as well as pure ruby stubs) and then tell them how to behave (return
>> values, raise errors and yield values).  I'll add subclassing of clr classes
>> and a nicer DSL for checking what actually happened.
>>
>>  See http://github.com/markryall/orangutan/tree/master and
>> http://github.com/casualjim/caricature/tree/master
>>
>>  Before long, we'll combine our efforts into one super mock object
>> library that will mock objects like they've never been mocked before.
>>
>>  Mark.
>>
>>  On Fri, May 8, 2009 at 5:00 AM, Shri Borde <[email protected]>wrote:
>>
>>>   This “newsletter” is just part of the contents of
>>> http://wiki.github.com/ironruby/ironruby/contributing for your reading
>>> convenience, filtered down to projects with an updated status since last
>>> time. A number of the projects have made good progress since a few weeks
>>> ago. Please take a look at the projects that interest you, give feedback to
>>> the project owners for bugs or features you care about, and discuss ways of
>>> being involved if you are interested.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Shri
>>>
>>>
>>>  Mixing Ruby mocking with .NET mocking frameworks
>>>
>>> Mark Ryall, Ivan Porto Carrero
>>>
>>> Investigated Moq and NMock and found that they were not a good match. A
>>> project called Caricature <http://github.com/casualjim/caricature/> has
>>> been started to implement mocking directly in IronRuby
>>> Hpricot <http://github.com/nrk/ironruby-hpricot/>
>>>
>>> Daniele Alessandri
>>>
>>> Status: the master branch (compatible with Hpricot 0.6.164) and the
>>> 0.7_experimental branch (compatible with Hpricot 0.8.1) in the repository
>>> both pass all the tests of the original Hpricot test suite, what is left is
>>> a major clean up and some refinements to the code.
>>> Json <http://github.com/nrk/ironruby-json>
>>>
>>> Daniele Alessandri
>>>
>>> Status: it somewhat works but needs to be tested, so bugs are expected at
>>> this stage. A rewriting of the original definition file for Ragel is planned
>>> to improve the C# code of the ParserEngine class which currently is not so
>>> object oriented.
>>> IRDb <http://github.com/rvernagus/irdb>
>>>
>>> Project State: Alpha
>>>
>>> Developer(s): Ray Vernagus <http://github.com/rvernagus>
>>>
>>> A Ruby wrapper on top of the .NET Data Provider 
>>> Model.<http://msdn.microsoft.com/en-us/library/a6cd7c08.aspx>This wrapper 
>>> will become the basis for an ActiveRecord adapter giving
>>> IronRuby developers the ability to use the ActiveRecord gem with their
>>> choice of database.
>>>   Rails <http://rubyonrails.org>
>>>
>>> Jimmy Schementi, Ray Vernagus
>>>
>>> Details status about setting up Rails, running the unit tests, etc, is at
>>> http://www.ironruby.net/Documentation/Rails.
>>> OpenSSL <http://www.ruby-doc.org/stdlib/libdoc/openssl/rdoc/index.html>
>>>
>>> Jirapong Nanta
>>>
>>> Status: There are about 330 methods for OpenSSL library. Less than ten
>>> RubySpec <http://wiki.github.com/ironruby/ironruby/rubyspec> are
>>> available. The focus of the project will be implementation the functionality
>>> that is needed for RubyGems and Rails scenarios. e.g.
>>> OpenSSL::X509::Certificate. Current results of running mspec ci
>>> library\openssl can be found here <http://gist.github.com/100649>.
>>>
>>> Work process:
>>>
>>> * Checkout ruby 1.8 source code
>>>
>>> * review OpenSsl implementation in C (ruby_1_8\ext\openssl)
>>>
>>> * review OpenSsl usage in RubyGems (e.g. 
>>> rubygems\lib\rubygems\gem_openssl.rb)
>>>
>>> * write RubySpec
>>>
>>> * implement a wrapper to System.Security.Cryptography namespaces
>>>
>>> * Refactor < - > Push
>>>
>>> Some useful documentations can be found at
>>> http://technorama.net/~oss/ruby/openssl/doc/
>>> Porting SOAP Weather 
>>> Widget<http://silverlight.net/community/gallerydetail.aspx?cat=sl2>
>>>
>>> Shay Friedman
>>>
>>> Status – project was created, started porting the Silverlight code.
>>> RubyGems
>>>
>>> Shri Borde, Jirapong Nanta
>>>
>>> We have reduced the number of failueres from 200+ down to about 20. The
>>> current results are here <http://gist.github.com/92738>. The tests can
>>> now be run from a 
>>> Dev.bat<http://wiki.github.com/ironruby/ironruby/devbat>environment, and 
>>> will soon be part of continuous integration. So this
>>> project is mostly wrapping up (successfully).
>>> Cucumber
>>>
>>> Chamini Gallage
>>>
>>> Blocking IronRuby bug has been fixed. Need to try again with a newer
>>> IronRuby version
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> [email protected]
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>>
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> [email protected]
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>>
>
> _______________________________________________
> Ironruby-core mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

Reply via email to