Hi folks. I''m very interested in the status of a port of any_instance from Mocha to RSpec. In particular I have a spec suite that I wrote using RSpec but with Mocha that depends heavily on any_instance. This is because it stubs out one or two methods from an underlying API. In attempting to convert the suite to RSpec mocks (because that''s what we''re using for the rest of the project) I had to give up. Attempting to replace objects by stubbing :new and returning mocks felt like a huge amount of busy work compared to one-line with any_instance. I noticed that Brian Takita appears to have an implementation of any_instance here: http://github.com/btakita/pain-point/tree/ca9a65e7110ccaa37175c741e1cea1aaa9776180/vendor/plugins/rspec/lib/spec/mocks which I tried, without success, to make work in my own version of rspec (1.1.4). I was able to call any_instance but it didn''t seem to be having an effect. I emailed Brian but I think he was at rails conf so I guess he may be fighting a backlog of work/email. Is there any likelyhood of any_instance making it into RSpec proper? If not, has anyone else had any luck implementing it? Regards, Matt. -- Matt Mower :: http://matt.blogs.it/
On Jun 4, 2008, at 4:19 AM, Matt Mower wrote:> Hi folks. > > I''m very interested in the status of a port of any_instance from > Mocha to RSpec. > > In particular I have a spec suite that I wrote using RSpec but with > Mocha that depends heavily on any_instance. This is because it stubs > out one or two methods from an underlying API. In attempting to > convert the suite to RSpec mocks (because that''s what we''re using for > the rest of the project) I had to give up. Attempting to replace > objects by stubbing :new and returning mocks felt like a huge amount > of busy work compared to one-line with any_instance. > > I noticed that Brian Takita appears to have an implementation of > any_instance here: > > http://github.com/btakita/pain-point/tree/ca9a65e7110ccaa37175c741e1cea1aaa9776180/vendor/plugins/rspec/lib/spec/mocks > > which I tried, without success, to make work in my own version of > rspec (1.1.4). I was able to call any_instance but it didn''t seem to > be having an effect. I emailed Brian but I think he was at rails conf > so I guess he may be fighting a backlog of work/email. > > Is there any likelyhood of any_instance making it into RSpec proper? > If not, has anyone else had any luck implementing it?There was an implementation of it that didn''t quite work for me in http://github.com/dchelimsky/rspec/commit/45a6837 so we reverted it. I have zero personal interest in this feature (use of which I find to be an anti-pattern) but am open to applying a patch as long as it meets criteria described in http://rspec.lighthouseapp.com/projects/5645/tickets/28 . Until such a patch comes my way, you can re-apply the existing patch (probably have to use git-format patch and tweak some things - any git- pros got advice on the best way to do that?) and it should work for most cases for you. Cheers, David
Hi David. On Wed, Jun 4, 2008 at 2:24 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> There was an implementation of it that didn''t quite work for me in > http://github.com/dchelimsky/rspec/commit/45a6837 so we reverted it. I have > zero personal interest in this feature (use of which I find to be an > anti-pattern) but am open to applying a patch as long as it meets criteria > described in http://rspec.lighthouseapp.com/projects/5645/tickets/28. >I''ve read the ticket, I was hoping it would explain why you feel any_instance is an anti-pattern. In my situation I am spec''ing a library that depends upon a lower-level for network operations. I use any_instance at certain points to simulate data coming from the network. Trying to stub :new and return a mock was very problematic for me because the object involved does some work with the data which my code depends upon for it''s own behaviour. Hence to test that I end up having to do a lot of work in my mocks and it quickly becomes cumbersome. What I really wanted was the "genuine" object with some behaviour changed which is what any_instance gives me. I tried searching the archives of this list but couldn''t find an article where you (or anyone else) expands on this view about any_instance. And thanks for the pointer, I guess I will try and assemble the patch and see if I can make it work. Regards, Matt. -- Matt Mower :: http://matt.blogs.it/
On Jun 4, 2008, at 9:40 AM, Matt Mower wrote:> Hi David. > > On Wed, Jun 4, 2008 at 2:24 PM, David Chelimsky > <dchelimsky at gmail.com> wrote: >> There was an implementation of it that didn''t quite work for me in >> http://github.com/dchelimsky/rspec/commit/45a6837 so we reverted >> it. I have >> zero personal interest in this feature (use of which I find to be an >> anti-pattern) but am open to applying a patch as long as it meets >> criteria >> described in http://rspec.lighthouseapp.com/projects/5645/tickets/28. >> > > I''ve read the ticket, I was hoping it would explain why you feel > any_instance is an anti-pattern. > > In my situation I am spec''ing a library that depends upon a > lower-level for network operations. I use any_instance at certain > points to simulate data coming from the network. > > Trying to stub :new and return a mock was very problematic for me > because the object involved does some work with the data which my code > depends upon for it''s own behaviour. Hence to test that I end up > having to do a lot of work in my mocks and it quickly becomes > cumbersome. > > What I really wanted was the "genuine" object with some behaviour > changed which is what any_instance gives me.Why can''t you give public access to the object? You''d then be able to stub it, just as with stub_all_instances. There''s a general idea with rspec (and one which probably isn''t present in other testing frameworks) that says that testing *should* influence your design. I''m sure this is one of the reasons that David considers it an "anti-pattern" - as it does not influence your design in any way. In fact, I developed the the stub_any_instance patch because I needed to test legacy code (legacy because it wasn''t designed well), and it was the only way to get to the object. I''m sure David would have specific examples, and I''d be curious to see them. Scott
HI Scott. On Thu, Jun 5, 2008 at 3:05 AM, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> There''s a general idea with rspec (and one which probably isn''t present in > other testing frameworks) that says that testing *should* influence your > design. I''m sure this is one of the reasons that David considers it an > "anti-pattern" - as it does not influence your design in any way. In fact, > I developed the the stub_any_instance patch because I needed to test legacy > code (legacy because it wasn''t designed well), and it was the only way to > get to the object.I guess that''s how I see this. My code, that I am writing specs for, depends upon a lower-level library that does not expose the details of it''s implementation to it''s clients. The use of any_instance allows me to test my code simply. Without it I seem to be forced to build complex arrangements of mocks to, essentially, emulate the behaviour of the underlying library. This feels like busy work. Whilst it would be possible to re-write the underlying library I do not feel that''s a worthwhile investment of my time right now. Especially not when I have a spec suite that already works but for the lack of any_instance. I''m all for encouraging good practice and wrapping any_instance in the shame of your peers. But I''m also all for being pragmatic. Does your patch work? I wasn''t clear whether David was saying that it doesn''t. Regards, Matt. -- Matt Mower :: http://matt.blogs.it/
On Jun 4, 2008, at 9:05 PM, Scott Taylor wrote:> There''s a general idea with rspec (and one which probably isn''t > present in other testing frameworks) that says that testing *should* > influence your design.This isn''t really a framework issue - it''s about TDD. Remember that BDD started off as another way of framing TDD - it''s roots are still in TDD. As you''ve read before, TDD is a design practice, not a testing practice. There is a testing benefit we get out of it, but the great benefit of writing tests first is that you start off thinking from a client''s perspective. This and the fact that you''re adding small bits at a time, doing the simplest thing that could possibly work, generally leads to more highly decoupled nuggets of code than back- filling tests.> I''m sure this is one of the reasons that David considers it an "anti- > pattern" - as it does not influence your design in any way. In > fact, I developed the the stub_any_instance patch because I needed > to test legacy code (legacy because it wasn''t designed well), and it > was the only way to get to the object. > > I''m sure David would have specific examples, and I''d be curious to > see them.any_instance is a global concept. Any time you''re doing something global in an executable example you''re making it harder for yourself to understand failures later. I guess that it''s a bit more harmless with stubs, so, as I said, I''m still open to adding a patch. I''m just not going to make it myself as it''s low priority for me. Cheers, David
On Jun 5, 2008, at 5:07 AM, Matt Mower wrote:> Does your patch work? I wasn''t clear whether David was saying that > it doesn''t.The patch works but is incomplete and duplicates a bunch of code. You should probably be able to use it as/is for what you need. Cheers, David