As I have been working more and more with testing C# via IronRuby & Rspec, I
have found myself wanting to use more and more of the rspec framework for
testing. I have also found problems that I am not sure how to work through
yet.
For instance lets say I have two c# classes:
public class Foo
{
private Bar _bar;
public Foo(Bar someBar)
{
this._bar = someBar;
}
public int GetBarCount()
{
return this._bar.Count;
}
}
public class Bar
{
private int _count = 0;
public Count
{
get { return _count;}
}
}
in my spec test I want to do something like this:
b = Bar.new
b.stub!(:Count).and_return(400)
f = Foo.new(b)
f.GetBarCount(),should == 100
The problem is that because I am stubbing the Bar instance via the dlr, the
CLR call on f never sees the stub and just returns 0.
Is there any way to make this work? I was wondering if I could maybe make
my Foo instance a proxy or mock itself and see if that would let the method
calls work... but I haven''t had any luck :(
-A
--
When I wrote this, only God and I understood what I was doing. Now, God
only knows - Karl Weierstrass
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100124/8161c898/attachment.html>
Ivan Porto Carrero
2010-Jan-24 18:38 UTC
[Ironruby-core] Mocking behavior between clr types
you can use caricature to solve that problem gem install caricature for rspec you do require ''caricature'' Spec::Runner.configure do |config| config.mock_with Caricature::RSpecAdapter config.include Caricature::RSpecMatchers end But it works slightly different as it won''t verify unless you tell it to verify. it has no mock or stub knowledge but works from the assumption you want to stub unless you add a verify call. the bacon integration specs show off all the combinations. --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Blog: http://flanders.co.nz Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) On Sun, Jan 24, 2010 at 7:19 PM, andrew Wilson <a.wilson82 at gmail.com> wrote:> As I have been working more and more with testing C# via IronRuby & Rspec, > I have found myself wanting to use more and more of the rspec framework for > testing. I have also found problems that I am not sure how to work through > yet. > > For instance lets say I have two c# classes: > > public class Foo > { > private Bar _bar; > > public Foo(Bar someBar) > { > this._bar = someBar; > } > > public int GetBarCount() > { > return this._bar.Count; > } > > } > > > public class Bar > { > private int _count = 0; > > public Count > { > get { return _count;} > } > } > > > in my spec test I want to do something like this: > > b = Bar.new > b.stub!(:Count).and_return(400) > > f = Foo.new(b) > f.GetBarCount(),should == 100 > > The problem is that because I am stubbing the Bar instance via the dlr, the > CLR call on f never sees the stub and just returns 0. > > Is there any way to make this work? I was wondering if I could maybe make > my Foo instance a proxy or mock itself and see if that would let the method > calls work... but I haven''t had any luck :( > > -A > > -- > When I wrote this, only God and I understood what I was doing. Now, God > only knows - Karl Weierstrass > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100124/6f255e9b/attachment-0001.html>
Ivan, Seems like a what I was looking for, however according to the documentation it says it can only mock virtuals and non-static though. I don''t want that restriction :( One of the advantages I was hoping to leverage was the ability to re-write methods that I wouldn''t otherwise be able to. -A -- When I wrote this, only God and I understood what I was doing. Now, God only knows - Karl Weierstrass -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100124/4edaa689/attachment.html>
> > I don''t want that restriction :( One of the advantages I was hoping to > leverage was the ability to re-write methods that I wouldn''t otherwise be > able to.Unfortunately that''s not a limitation put there by Caricature, but one put there by the CLR itself. Unless you want to get into disassembling and reassembling your dll''s on the fly, you''re out of luck -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100125/71715662/attachment.html>
"disassembling and reassembling your dll''s on the fly" That sounds like fun..... hmmmm, I''ll think that one over a little bit. On a similar note, you might be interested in my presentation on Testing ASP.net applications using C# http://blog.benhall.me.uk/2010/01/testing-aspnet-using-ruby-codemash.html Ben On Sun, Jan 24, 2010 at 7:31 PM, Orion Edwards <orion.edwards at gmail.com> wrote:>> I don''t want that restriction :(? One of the advantages I was hoping to >> leverage was the ability to re-write methods that I wouldn''t otherwise be >> able to. > > Unfortunately that''s not a limitation put there by Caricature, but one put > there by the CLR itself. Unless you want to get into?disassembling?and > reassembling your dll''s on the fly, you''re out of luck > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >
Ivan Porto Carrero
2010-Jan-24 20:34 UTC
[Ironruby-core] Mocking behavior between clr types
You don''t need to do anything as drastic as disassemble dlls though :). There are several solutions and I think the cleanest one is to use the CLR profiling API. Another avenue I could take is to use Mono.Cecil but I don''t like the idea of the IL rewriting stuff. heck even postsharp would probably do the trick. I need to look into the CLR profiling API to make the rest of the stuff happening as that is the cleanest solution IMO. The limitation only exists if you''re mocking CLR classes for use in other CLR classes. If you''re going to use it in ruby code you can do whatever you want. My mocker does most of what Moq and Rhino.Mocks do, except that it doesn''t use LCG or expression trees but just the reflection API once per type. from there on out it uses ruby to do its job. What I need to add but don''t know if they are really necessary are call count constraints. And I also want to make the RSpec integration a little bit better so that you can enlist an expectation for verification too. The docs are a bit outdated too, best is to look into spec/bacon/integration that''s where I test out the new features or syntax additions. I have a chapter in my book that explains the use of Caricature with RSpec which will be in the update at the end of january. Contact me off list if you want a discount :) --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Blog: http://flanders.co.nz Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) On Sun, Jan 24, 2010 at 8:16 PM, andrew Wilson <a.wilson82 at gmail.com> wrote:> Ivan, > > Seems like a what I was looking for, however according to the documentation > it says it can only mock virtuals and non-static though. > > I don''t want that restriction :( One of the advantages I was hoping to > leverage was the ability to re-write methods that I wouldn''t otherwise be > able to. > > > -A > > -- > When I wrote this, only God and I understood what I was doing. Now, God > only knows - Karl Weierstrass > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100124/8a67fda1/attachment.html>
Hi Ivan, I was thinking Mono.Cecil first and then the CLR profiling API as I''m pretty sure that will work. I used a similar approach for http://blog.benhall.me.uk/2008/11/net-fault-injection-very-early-proof-of.html but the fault injection was done via some Microsoft Research stuff. Either approach your re-writing IL, it just depends which layer you work with. Lots of interesting problems to solve. Then it would just need a nice Ruby wrapper so it''s transparent to the end user - ideally incorporating the backend work into Caricature. Ben On Sun, Jan 24, 2010 at 8:34 PM, Ivan Porto Carrero <ivan at flanders.co.nz> wrote:> You don''t need to do anything as drastic as disassemble dlls though :). > There are several solutions and I think the cleanest one is to use the CLR > profiling API. ?Another avenue I could take is to use Mono.Cecil but I don''t > like the idea of the IL rewriting stuff. heck even postsharp would probably > do the trick. > I need to look into the CLR profiling API to make the rest of the stuff > happening as that is the cleanest solution IMO. The limitation only exists > if you''re mocking CLR classes for use in other CLR classes. If you''re going > to use it in ruby code you can do whatever you want. > My mocker does most of what Moq and Rhino.Mocks do, except that it doesn''t > use LCG or expression trees but just the reflection API once per type. from > there on out it uses ruby to do its job. > What I need to add but don''t know if they are really necessary are?call > count constraints. > And I also want to make the RSpec integration a little bit better so that > you can enlist an expectation for verification too. > The docs are a bit outdated too, best is to look into spec/bacon/integration > that''s where I test out the new features or syntax additions. > I have a chapter in my book that explains the use of Caricature with RSpec > which will be in the update at the end of january. Contact me off list if > you want a discount :) > --- > Met vriendelijke groeten - Best regards - Salutations > Ivan Porto Carrero > Blog: http://flanders.co.nz > Twitter: http://twitter.com/casualjim > Author of IronRuby in Action (http://manning.com/carrero) > > > > On Sun, Jan 24, 2010 at 8:16 PM, andrew Wilson <a.wilson82 at gmail.com> wrote: >> >> Ivan, >> >> Seems like a what I was looking for, however according to the >> documentation it says it can only mock virtuals and non-static though. >> >> I don''t want that restriction :(? One of the advantages I was hoping to >> leverage was the ability to re-write methods that I wouldn''t otherwise be >> able to. >> >> -A >> >> -- >> When I wrote this, only God and I understood what I was doing. ?Now, God >> only knows - Karl Weierstrass >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >
Basically, Ruby is able to do all the crazy mocking stuff because of its mutable type system, and the only way to make the CLR''s type-system mutable is to rewrite the IL. To put it in SAT terms: "rewriting IL" is to "static languages" as "monkey-patching" is to "dynamic languages" =P ~Jimmy> -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Ben Hall > Sent: Sunday, January 24, 2010 1:31 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Mocking behavior between clr types > > Hi Ivan, > > I was thinking Mono.Cecil first and then the CLR profiling API as I''m pretty > sure that will work. I used a similar approach for > http://blog.benhall.me.uk/2008/11/net-fault-injection-very-early-proof- > of.html > but the fault injection was done via some Microsoft Research stuff. > Either approach your re-writing IL, it just depends which layer you work > with. > > Lots of interesting problems to solve. Then it would just need a nice Ruby > wrapper so it''s transparent to the end user - ideally incorporating the > backend work into Caricature. > > Ben > > On Sun, Jan 24, 2010 at 8:34 PM, Ivan Porto Carrero <ivan at flanders.co.nz> > wrote: > > You don''t need to do anything as drastic as disassemble dlls though :). > > There are several solutions and I think the cleanest one is to use the > > CLR profiling API. ?Another avenue I could take is to use Mono.Cecil > > but I don''t like the idea of the IL rewriting stuff. heck even > > postsharp would probably do the trick. > > I need to look into the CLR profiling API to make the rest of the > > stuff happening as that is the cleanest solution IMO. The limitation > > only exists if you''re mocking CLR classes for use in other CLR > > classes. If you''re going to use it in ruby code you can do whatever you > want. > > My mocker does most of what Moq and Rhino.Mocks do, except that it > > doesn''t use LCG or expression trees but just the reflection API once > > per type. from there on out it uses ruby to do its job. > > What I need to add but don''t know if they are really necessary are > > call count constraints. > > And I also want to make the RSpec integration a little bit better so > > that you can enlist an expectation for verification too. > > The docs are a bit outdated too, best is to look into > > spec/bacon/integration that''s where I test out the new features or syntax > additions. > > I have a chapter in my book that explains the use of Caricature with > > RSpec which will be in the update at the end of january. Contact me > > off list if you want a discount :) > > --- > > Met vriendelijke groeten - Best regards - Salutations Ivan Porto > > Carrero > > Blog: http://flanders.co.nz > > Twitter: http://twitter.com/casualjim > > Author of IronRuby in Action (http://manning.com/carrero) > > > > > > > > On Sun, Jan 24, 2010 at 8:16 PM, andrew Wilson <a.wilson82 at gmail.com> > wrote: > >> > >> Ivan, > >> > >> Seems like a what I was looking for, however according to the > >> documentation it says it can only mock virtuals and non-static though. > >> > >> I don''t want that restriction :(? One of the advantages I was hoping > >> to leverage was the ability to re-write methods that I wouldn''t > >> otherwise be able to. > >> > >> -A > >> > >> -- > >> When I wrote this, only God and I understood what I was doing. ?Now, > >> God only knows - Karl Weierstrass > >> > >> _______________________________________________ > >> Ironruby-core mailing list > >> Ironruby-core at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/ironruby-core > >> > > > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core
Ivan Porto Carrero
2010-Jan-26 09:03 UTC
[Ironruby-core] Mocking behavior between clr types
I''m not sure if the CLR profiling API is in Mono I''d have to find that out first. My thing against mono.cecil is that you need to instrument the DLL and rewrite the IL before running your app. I''d prefer to do stuff during instead of beforehand. I need to be able to intercept and decide whether to go on or not. I''ve been googling the CLR profiling API a little yesterday, and I have to go through the mailinglist archive to find the links Shri sent me last year about this subject. I did get the expert IL assembler book which also came out of that discussion but haven''t gotten round to actually reading it yet. --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Blog: http://flanders.co.nz Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) On Tue, Jan 26, 2010 at 9:43 AM, Jimmy Schementi < Jimmy.Schementi at microsoft.com> wrote:> Basically, Ruby is able to do all the crazy mocking stuff because of its > mutable type system, and the only way to make the CLR''s type-system mutable > is to rewrite the IL. To put it in SAT terms: > > "rewriting IL" is to "static languages" as "monkey-patching" is to "dynamic > languages" > > =P > > ~Jimmy > > > > -----Original Message----- > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > > bounces at rubyforge.org] On Behalf Of Ben Hall > > Sent: Sunday, January 24, 2010 1:31 PM > > To: ironruby-core at rubyforge.org > > Subject: Re: [Ironruby-core] Mocking behavior between clr types > > > > Hi Ivan, > > > > I was thinking Mono.Cecil first and then the CLR profiling API as I''m > pretty > > sure that will work. I used a similar approach for > > http://blog.benhall.me.uk/2008/11/net-fault-injection-very-early-proof- > > of.html > > but the fault injection was done via some Microsoft Research stuff. > > Either approach your re-writing IL, it just depends which layer you work > > with. > > > > Lots of interesting problems to solve. Then it would just need a nice > Ruby > > wrapper so it''s transparent to the end user - ideally incorporating the > > backend work into Caricature. > > > > Ben > > > > On Sun, Jan 24, 2010 at 8:34 PM, Ivan Porto Carrero <ivan at flanders.co.nz > > > > wrote: > > > You don''t need to do anything as drastic as disassemble dlls though :). > > > There are several solutions and I think the cleanest one is to use the > > > CLR profiling API. Another avenue I could take is to use Mono.Cecil > > > but I don''t like the idea of the IL rewriting stuff. heck even > > > postsharp would probably do the trick. > > > I need to look into the CLR profiling API to make the rest of the > > > stuff happening as that is the cleanest solution IMO. The limitation > > > only exists if you''re mocking CLR classes for use in other CLR > > > classes. If you''re going to use it in ruby code you can do whatever you > > want. > > > My mocker does most of what Moq and Rhino.Mocks do, except that it > > > doesn''t use LCG or expression trees but just the reflection API once > > > per type. from there on out it uses ruby to do its job. > > > What I need to add but don''t know if they are really necessary are > > > call count constraints. > > > And I also want to make the RSpec integration a little bit better so > > > that you can enlist an expectation for verification too. > > > The docs are a bit outdated too, best is to look into > > > spec/bacon/integration that''s where I test out the new features or > syntax > > additions. > > > I have a chapter in my book that explains the use of Caricature with > > > RSpec which will be in the update at the end of january. Contact me > > > off list if you want a discount :) > > > --- > > > Met vriendelijke groeten - Best regards - Salutations Ivan Porto > > > Carrero > > > Blog: http://flanders.co.nz > > > Twitter: http://twitter.com/casualjim > > > Author of IronRuby in Action (http://manning.com/carrero) > > > > > > > > > > > > On Sun, Jan 24, 2010 at 8:16 PM, andrew Wilson <a.wilson82 at gmail.com> > > wrote: > > >> > > >> Ivan, > > >> > > >> Seems like a what I was looking for, however according to the > > >> documentation it says it can only mock virtuals and non-static though. > > >> > > >> I don''t want that restriction :( One of the advantages I was hoping > > >> to leverage was the ability to re-write methods that I wouldn''t > > >> otherwise be able to. > > >> > > >> -A > > >> > > >> -- > > >> When I wrote this, only God and I understood what I was doing. Now, > > >> God only knows - Karl Weierstrass > > >> > > >> _______________________________________________ > > >> Ironruby-core mailing list > > >> Ironruby-core at rubyforge.org > > >> http://rubyforge.org/mailman/listinfo/ironruby-core > > >> > > > > > > > > > _______________________________________________ > > > Ironruby-core mailing list > > > Ironruby-core at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100126/0e79da62/attachment-0001.html>
TypeMock is doing thing slightly different that allows you to intercept essentially calls to any member (static, sealed types, non-virtuals, etc). It take sa different approach than Rhino and Moq, I''m not sure if something similar could be done using Ruby, I''m just dropping the idea here.... On Mon, Jan 25, 2010 at 7:34 AM, Ivan Porto Carrero <ivan at flanders.co.nz>wrote:> You don''t need to do anything as drastic as disassemble dlls though :). > There are several solutions and I think the cleanest one is to use the CLR > profiling API. Another avenue I could take is to use Mono.Cecil but I don''t > like the idea of the IL rewriting stuff. heck even postsharp would probably > do the trick. > > I need to look into the CLR profiling API to make the rest of the stuff > happening as that is the cleanest solution IMO. The limitation only exists > if you''re mocking CLR classes for use in other CLR classes. If you''re going > to use it in ruby code you can do whatever you want. > > My mocker does most of what Moq and Rhino.Mocks do, except that it doesn''t > use LCG or expression trees but just the reflection API once per type. from > there on out it uses ruby to do its job. > > What I need to add but don''t know if they are really necessary are call > count constraints. > And I also want to make the RSpec integration a little bit better so that > you can enlist an expectation for verification too. > > The docs are a bit outdated too, best is to look into > spec/bacon/integration that''s where I test out the new features or syntax > additions. > I have a chapter in my book that explains the use of Caricature with RSpec > which will be in the update at the end of january. Contact me off list if > you want a discount :) > > --- > Met vriendelijke groeten - Best regards - Salutations > Ivan Porto Carrero > Blog: http://flanders.co.nz > Twitter: http://twitter.com/casualjim > Author of IronRuby in Action (http://manning.com/carrero) > > > > On Sun, Jan 24, 2010 at 8:16 PM, andrew Wilson <a.wilson82 at gmail.com>wrote: > >> Ivan, >> >> Seems like a what I was looking for, however according to the >> documentation it says it can only mock virtuals and non-static though. >> >> I don''t want that restriction :( One of the advantages I was hoping to >> leverage was the ability to re-write methods that I wouldn''t otherwise be >> able to. >> >> >> -A >> >> -- >> When I wrote this, only God and I understood what I was doing. Now, God >> only knows - Karl Weierstrass >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-- Miguel A. Madero Reyes www.miguelmadero.com (blog) me at miguelmadero.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100127/b0891d4a/attachment-0001.html>
Ivan Porto Carrero
2010-Jan-27 05:58 UTC
[Ironruby-core] Mocking behavior between clr types
yes typemock uses the CLR profiling API and is a paid product. I don''t know if typemock runs on Mono either, couldn''t find it on their website. For me running on mono is one of the base requirements of my mocker, because I''m too often on my mac or linux machines to neglect that. That being said 99% of your tests will not need to mock a static method, and if you know about the limitation you can work around it if you''re in control of the code. I''ve looked into this now and I can''t find the ICorProfilerCallback2 interface in Mono on my mac. Mono allows you to write a profiler too though but AFAICT that has to be written in C, which I don''t know, and it would also require to start mono with a different set of parameters. So I guess the way forward is mono.cecil, but I don''t like the approach I need to take at all: Backup the assemblies in the bin before running the tests instrument every assembly in the bin folder with all the static method calls wrapped inside a before and after hook. These hooks call out to caricature and provide the mocking behavior. Save the modified assembly in the bin run the test. if there is an error or an interrupt or exit, restore assemblies from backup and this can go wrong easily. It also means I have to make it a requirement to require caricature before requiring any of your application code in the test_helper or spec_helper file. If somebody has a better solution by all means share, or better yet put it in and send me a pull request --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Blog: http://flanders.co.nz Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) On Wed, Jan 27, 2010 at 4:50 AM, Miguel Madero <me at miguelmadero.com> wrote:> TypeMock is doing thing slightly different that allows you to intercept > essentially calls to any member (static, sealed types, non-virtuals, etc). > It take sa different approach than Rhino and Moq, I''m not sure if something > similar could be done using Ruby, I''m just dropping the idea here.... > > On Mon, Jan 25, 2010 at 7:34 AM, Ivan Porto Carrero <ivan at flanders.co.nz>wrote: > >> You don''t need to do anything as drastic as disassemble dlls though :). >> There are several solutions and I think the cleanest one is to use the CLR >> profiling API. Another avenue I could take is to use Mono.Cecil but I don''t >> like the idea of the IL rewriting stuff. heck even postsharp would probably >> do the trick. >> >> I need to look into the CLR profiling API to make the rest of the stuff >> happening as that is the cleanest solution IMO. The limitation only exists >> if you''re mocking CLR classes for use in other CLR classes. If you''re going >> to use it in ruby code you can do whatever you want. >> >> My mocker does most of what Moq and Rhino.Mocks do, except that it doesn''t >> use LCG or expression trees but just the reflection API once per type. from >> there on out it uses ruby to do its job. >> >> What I need to add but don''t know if they are really necessary are call >> count constraints. >> And I also want to make the RSpec integration a little bit better so that >> you can enlist an expectation for verification too. >> >> The docs are a bit outdated too, best is to look into >> spec/bacon/integration that''s where I test out the new features or syntax >> additions. >> I have a chapter in my book that explains the use of Caricature with RSpec >> which will be in the update at the end of january. Contact me off list if >> you want a discount :) >> >> --- >> Met vriendelijke groeten - Best regards - Salutations >> Ivan Porto Carrero >> Blog: http://flanders.co.nz >> Twitter: http://twitter.com/casualjim >> Author of IronRuby in Action (http://manning.com/carrero) >> >> >> >> On Sun, Jan 24, 2010 at 8:16 PM, andrew Wilson <a.wilson82 at gmail.com>wrote: >> >>> Ivan, >>> >>> Seems like a what I was looking for, however according to the >>> documentation it says it can only mock virtuals and non-static though. >>> >>> I don''t want that restriction :( One of the advantages I was hoping to >>> leverage was the ability to re-write methods that I wouldn''t otherwise be >>> able to. >>> >>> >>> -A >>> >>> -- >>> When I wrote this, only God and I understood what I was doing. Now, God >>> only knows - Karl Weierstrass >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> > > > -- > Miguel A. Madero Reyes > www.miguelmadero.com (blog) > me at miguelmadero.com > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100127/3a220f2d/attachment.html>
Ivan Porto Carrero
2010-Jan-27 09:17 UTC
[Ironruby-core] Mocking behavior between clr types
Well this is going to be a very interesting problem to solve when I''m done with the edits on my book. ICorProfilerCallback2 is windows only Mono.Cecil requires steps before running the app On the mono IRC channel I''m told that there is no other way to do it in mono. --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Blog: http://flanders.co.nz Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) On Wed, Jan 27, 2010 at 6:58 AM, Ivan Porto Carrero <ivan at flanders.co.nz>wrote:> yes typemock uses the CLR profiling API and is a paid product. I don''t know > if typemock runs on Mono either, couldn''t find it on their website. > For me running on mono is one of the base requirements of my mocker, > because I''m too often on my mac or linux machines to neglect that. > > That being said 99% of your tests will not need to mock a static method, > and if you know about the limitation you can work around it if you''re in > control of the code. > > I''ve looked into this now and I can''t find the ICorProfilerCallback2 > interface in Mono on my mac. Mono allows you to write a profiler too though > but AFAICT that has to be written in C, which I don''t know, and it would > also require to start mono with a different set of parameters. > > So I guess the way forward is mono.cecil, but I don''t like the approach I > need to take at all: > > Backup the assemblies in the bin > before running the tests instrument every assembly in the bin folder with > all the static method calls wrapped inside a before and after hook. These > hooks call out to caricature and provide the mocking behavior. > Save the modified assembly in the bin > > run the test. > > if there is an error or an interrupt or exit, restore assemblies from > backup and this can go wrong easily. > > It also means I have to make it a requirement to require caricature before > requiring any of your application code in the test_helper or spec_helper > file. > > If somebody has a better solution by all means share, or better yet put it > in and send me a pull request > > --- > Met vriendelijke groeten - Best regards - Salutations > Ivan Porto Carrero > Blog: http://flanders.co.nz > Twitter: http://twitter.com/casualjim > Author of IronRuby in Action (http://manning.com/carrero) > > > > On Wed, Jan 27, 2010 at 4:50 AM, Miguel Madero <me at miguelmadero.com>wrote: > >> TypeMock is doing thing slightly different that allows you to intercept >> essentially calls to any member (static, sealed types, non-virtuals, etc). >> It take sa different approach than Rhino and Moq, I''m not sure if something >> similar could be done using Ruby, I''m just dropping the idea here.... >> >> On Mon, Jan 25, 2010 at 7:34 AM, Ivan Porto Carrero <ivan at flanders.co.nz>wrote: >> >>> You don''t need to do anything as drastic as disassemble dlls though :). >>> There are several solutions and I think the cleanest one is to use the >>> CLR profiling API. Another avenue I could take is to use Mono.Cecil but I >>> don''t like the idea of the IL rewriting stuff. heck even postsharp would >>> probably do the trick. >>> >>> I need to look into the CLR profiling API to make the rest of the stuff >>> happening as that is the cleanest solution IMO. The limitation only exists >>> if you''re mocking CLR classes for use in other CLR classes. If you''re going >>> to use it in ruby code you can do whatever you want. >>> >>> My mocker does most of what Moq and Rhino.Mocks do, except that it >>> doesn''t use LCG or expression trees but just the reflection API once per >>> type. from there on out it uses ruby to do its job. >>> >>> What I need to add but don''t know if they are really necessary are call >>> count constraints. >>> And I also want to make the RSpec integration a little bit better so that >>> you can enlist an expectation for verification too. >>> >>> The docs are a bit outdated too, best is to look into >>> spec/bacon/integration that''s where I test out the new features or syntax >>> additions. >>> I have a chapter in my book that explains the use of Caricature with >>> RSpec which will be in the update at the end of january. Contact me off list >>> if you want a discount :) >>> >>> --- >>> Met vriendelijke groeten - Best regards - Salutations >>> Ivan Porto Carrero >>> Blog: http://flanders.co.nz >>> Twitter: http://twitter.com/casualjim >>> Author of IronRuby in Action (http://manning.com/carrero) >>> >>> >>> >>> On Sun, Jan 24, 2010 at 8:16 PM, andrew Wilson <a.wilson82 at gmail.com>wrote: >>> >>>> Ivan, >>>> >>>> Seems like a what I was looking for, however according to the >>>> documentation it says it can only mock virtuals and non-static though. >>>> >>>> I don''t want that restriction :( One of the advantages I was hoping to >>>> leverage was the ability to re-write methods that I wouldn''t otherwise be >>>> able to. >>>> >>>> >>>> -A >>>> >>>> -- >>>> When I wrote this, only God and I understood what I was doing. Now, God >>>> only knows - Karl Weierstrass >>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>>> >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >> >> >> -- >> Miguel A. Madero Reyes >> www.miguelmadero.com (blog) >> me at miguelmadero.com >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100127/abad4265/attachment.html>
ICorProfilerCallback2 requires C\COM scaryness :) On Wed, Jan 27, 2010 at 9:17 AM, Ivan Porto Carrero <ivan at flanders.co.nz> wrote:> Well this is going to be a very interesting problem to solve when I''m done > with the edits on my book. > ICorProfilerCallback2 is windows only > Mono.Cecil requires steps before running the app > On the mono IRC channel I''m told that there is no other way to do it in > mono. > > --- > Met vriendelijke groeten - Best regards - Salutations > Ivan Porto Carrero > Blog: http://flanders.co.nz > Twitter: http://twitter.com/casualjim > Author of IronRuby in Action (http://manning.com/carrero) > > > > On Wed, Jan 27, 2010 at 6:58 AM, Ivan Porto Carrero <ivan at flanders.co.nz> > wrote: >> >> yes typemock uses the CLR profiling API and is a paid product. I don''t >> know if typemock runs on Mono either, couldn''t find it on their website. >> For me running on mono is one of the base requirements of my mocker, >> because I''m too often on my mac or linux machines to neglect that. >> That being said 99% of your tests will not need to mock a static method, >> and if you know about the limitation you can work around it if you''re in >> control of the code. >> I''ve looked into this now and I can''t find the ICorProfilerCallback2 >> interface in Mono on my mac. Mono allows you to write a profiler too though >> but AFAICT that has to be written in C, which I don''t know, and it would >> also require to start mono with a different set of parameters. >> So I guess the way forward is mono.cecil, but I don''t like the approach I >> need to take at all: >> Backup the assemblies in the bin >> before running the tests instrument every assembly in the bin folder with >> all the static method calls wrapped inside a before and after hook. These >> hooks call out to caricature and provide the mocking behavior. >> Save the modified assembly in the bin >> run the test. >> if there is an error or an interrupt or exit, restore assemblies from >> backup and this can go wrong easily. >> It also means I have to make it a requirement to require caricature before >> requiring any of your application code in the test_helper or spec_helper >> file. >> If somebody has a better solution by all means share, or better yet put it >> in and send me a pull request >> --- >> Met vriendelijke groeten - Best regards - Salutations >> Ivan Porto Carrero >> Blog: http://flanders.co.nz >> Twitter: http://twitter.com/casualjim >> Author of IronRuby in Action (http://manning.com/carrero) >> >> >> >> On Wed, Jan 27, 2010 at 4:50 AM, Miguel Madero <me at miguelmadero.com> >> wrote: >>> >>> TypeMock is doing thing slightly different that allows you to intercept >>> essentially calls to any member (static, sealed types, non-virtuals, etc). >>> It take sa different approach than Rhino and Moq, I''m not sure if something >>> similar could be done using Ruby, I''m just dropping the idea here.... >>> >>> On Mon, Jan 25, 2010 at 7:34 AM, Ivan Porto Carrero <ivan at flanders.co.nz> >>> wrote: >>>> >>>> You don''t need to do anything as drastic as disassemble dlls though :). >>>> There are several solutions and I think the cleanest one is to use the >>>> CLR profiling API. ?Another avenue I could take is to use Mono.Cecil but I >>>> don''t like the idea of the IL rewriting stuff. heck even postsharp would >>>> probably do the trick. >>>> I need to look into the CLR profiling API to make the rest of the stuff >>>> happening as that is the cleanest solution IMO. The limitation only exists >>>> if you''re mocking CLR classes for use in other CLR classes. If you''re going >>>> to use it in ruby code you can do whatever you want. >>>> My mocker does most of what Moq and Rhino.Mocks do, except that it >>>> doesn''t use LCG or expression trees but just the reflection API once per >>>> type. from there on out it uses ruby to do its job. >>>> What I need to add but don''t know if they are really necessary are?call >>>> count constraints. >>>> And I also want to make the RSpec integration a little bit better so >>>> that you can enlist an expectation for verification too. >>>> The docs are a bit outdated too, best is to look into >>>> spec/bacon/integration that''s where I test out the new features or syntax >>>> additions. >>>> I have a chapter in my book that explains the use of Caricature with >>>> RSpec which will be in the update at the end of january. Contact me off list >>>> if you want a discount :) >>>> --- >>>> Met vriendelijke groeten - Best regards - Salutations >>>> Ivan Porto Carrero >>>> Blog: http://flanders.co.nz >>>> Twitter: http://twitter.com/casualjim >>>> Author of IronRuby in Action (http://manning.com/carrero) >>>> >>>> >>>> >>>> On Sun, Jan 24, 2010 at 8:16 PM, andrew Wilson <a.wilson82 at gmail.com> >>>> wrote: >>>>> >>>>> Ivan, >>>>> >>>>> Seems like a what I was looking for, however according to the >>>>> documentation it says it can only mock virtuals and non-static though. >>>>> >>>>> I don''t want that restriction :(? One of the advantages I was hoping to >>>>> leverage was the ability to re-write methods that I wouldn''t otherwise be >>>>> able to. >>>>> >>>>> -A >>>>> >>>>> -- >>>>> When I wrote this, only God and I understood what I was doing. ?Now, >>>>> God only knows - Karl Weierstrass >>>>> >>>>> _______________________________________________ >>>>> Ironruby-core mailing list >>>>> Ironruby-core at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>> >>> >>> >>> -- >>> Miguel A. Madero Reyes >>> www.miguelmadero.com (blog) >>> me at miguelmadero.com >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >> > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >
One suggestion would be to prototype with Mono.Cecil to do the IL rewriting and get rcov working with that. If that does work, then it might turn out to be an acceptable solution inspite of the need to instrument the assemblies up front since you don''t do coverage runs too often. If the instrumenting is not acceptable at that point, I am sure we can find samples using ICorProfilerCallback2 that can be used to do the IL rewriting on the fly. -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ben Hall Sent: Wednesday, January 27, 2010 2:40 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Mocking behavior between clr types ICorProfilerCallback2 requires C\COM scaryness :) On Wed, Jan 27, 2010 at 9:17 AM, Ivan Porto Carrero <ivan at flanders.co.nz> wrote:> Well this is going to be a very interesting problem to solve when I''m done > with the edits on my book. > ICorProfilerCallback2 is windows only > Mono.Cecil requires steps before running the app > On the mono IRC channel I''m told that there is no other way to do it in > mono. > > --- > Met vriendelijke groeten - Best regards - Salutations > Ivan Porto Carrero > Blog: http://flanders.co.nz > Twitter: http://twitter.com/casualjim > Author of IronRuby in Action (http://manning.com/carrero) > > > > On Wed, Jan 27, 2010 at 6:58 AM, Ivan Porto Carrero <ivan at flanders.co.nz> > wrote: >> >> yes typemock uses the CLR profiling API and is a paid product. I don''t >> know if typemock runs on Mono either, couldn''t find it on their website. >> For me running on mono is one of the base requirements of my mocker, >> because I''m too often on my mac or linux machines to neglect that. >> That being said 99% of your tests will not need to mock a static method, >> and if you know about the limitation you can work around it if you''re in >> control of the code. >> I''ve looked into this now and I can''t find the ICorProfilerCallback2 >> interface in Mono on my mac. Mono allows you to write a profiler too though >> but AFAICT that has to be written in C, which I don''t know, and it would >> also require to start mono with a different set of parameters. >> So I guess the way forward is mono.cecil, but I don''t like the approach I >> need to take at all: >> Backup the assemblies in the bin >> before running the tests instrument every assembly in the bin folder with >> all the static method calls wrapped inside a before and after hook. These >> hooks call out to caricature and provide the mocking behavior. >> Save the modified assembly in the bin >> run the test. >> if there is an error or an interrupt or exit, restore assemblies from >> backup and this can go wrong easily. >> It also means I have to make it a requirement to require caricature before >> requiring any of your application code in the test_helper or spec_helper >> file. >> If somebody has a better solution by all means share, or better yet put it >> in and send me a pull request >> --- >> Met vriendelijke groeten - Best regards - Salutations >> Ivan Porto Carrero >> Blog: http://flanders.co.nz >> Twitter: http://twitter.com/casualjim >> Author of IronRuby in Action (http://manning.com/carrero) >> >> >> >> On Wed, Jan 27, 2010 at 4:50 AM, Miguel Madero <me at miguelmadero.com> >> wrote: >>> >>> TypeMock is doing thing slightly different that allows you to intercept >>> essentially calls to any member (static, sealed types, non-virtuals, etc). >>> It take sa different approach than Rhino and Moq, I''m not sure if something >>> similar could be done using Ruby, I''m just dropping the idea here.... >>> >>> On Mon, Jan 25, 2010 at 7:34 AM, Ivan Porto Carrero <ivan at flanders.co.nz> >>> wrote: >>>> >>>> You don''t need to do anything as drastic as disassemble dlls though :). >>>> There are several solutions and I think the cleanest one is to use the >>>> CLR profiling API. ?Another avenue I could take is to use Mono.Cecil but I >>>> don''t like the idea of the IL rewriting stuff. heck even postsharp would >>>> probably do the trick. >>>> I need to look into the CLR profiling API to make the rest of the stuff >>>> happening as that is the cleanest solution IMO. The limitation only exists >>>> if you''re mocking CLR classes for use in other CLR classes. If you''re going >>>> to use it in ruby code you can do whatever you want. >>>> My mocker does most of what Moq and Rhino.Mocks do, except that it >>>> doesn''t use LCG or expression trees but just the reflection API once per >>>> type. from there on out it uses ruby to do its job. >>>> What I need to add but don''t know if they are really necessary are?call >>>> count constraints. >>>> And I also want to make the RSpec integration a little bit better so >>>> that you can enlist an expectation for verification too. >>>> The docs are a bit outdated too, best is to look into >>>> spec/bacon/integration that''s where I test out the new features or syntax >>>> additions. >>>> I have a chapter in my book that explains the use of Caricature with >>>> RSpec which will be in the update at the end of january. Contact me off list >>>> if you want a discount :) >>>> --- >>>> Met vriendelijke groeten - Best regards - Salutations >>>> Ivan Porto Carrero >>>> Blog: http://flanders.co.nz >>>> Twitter: http://twitter.com/casualjim >>>> Author of IronRuby in Action (http://manning.com/carrero) >>>> >>>> >>>> >>>> On Sun, Jan 24, 2010 at 8:16 PM, andrew Wilson <a.wilson82 at gmail.com> >>>> wrote: >>>>> >>>>> Ivan, >>>>> >>>>> Seems like a what I was looking for, however according to the >>>>> documentation it says it can only mock virtuals and non-static though. >>>>> >>>>> I don''t want that restriction :(? One of the advantages I was hoping to >>>>> leverage was the ability to re-write methods that I wouldn''t otherwise be >>>>> able to. >>>>> >>>>> -A >>>>> >>>>> -- >>>>> When I wrote this, only God and I understood what I was doing. ?Now, >>>>> God only knows - Karl Weierstrass >>>>> >>>>> _______________________________________________ >>>>> Ironruby-core mailing list >>>>> Ironruby-core at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>> >>> >>> >>> -- >>> Miguel A. Madero Reyes >>> www.miguelmadero.com (blog) >>> me at miguelmadero.com >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >> > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >_______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core