I'm new to ruby and OOP - your talk accelerated understanding - I wish there were an entire series of this kind of presentation. Seeing the code made ALL the difference.
Hi Sandi. I just saw the video of your SOLID talk and really enjoyed it. (BTW, I'm doing a SOLID Ruby at RubyConf, but it goes a slightly different direction than yours).
But, I have a question. In passing you mentioned that you only mock your own code, not code belonging to others. I would love to hear you elaborate on reasons for this.
One mocking hole I repeatedly dig and then must climb out of involves testing across the boundary where my code interacts with an external api.
My goal is to use testing to make my coding more productive and to use mocking to make my testing more productive. In dealing with external libraries I kept failing at this; my testing turned into a high maintenance nightmare that cost more than it returned. I would try to mock the external api but I always ended up writing a lot of fragile, non-intention revealing, test polluting code that wasn't quite right.
Ah ha. The lightbulb comes on. The idea that difficulty in writing tests reveals a design problem that should be listened to is exactly right in my case.
Their suggestion to write an adaptor that exposes only the relevant parts of the external api has many advantages. It lets me simplify the interface as far as MY application is concerned. It gives me a level of indirection that allows me to easily swap to a different external library. I can mock my own adaptor and thus have very clear, intention revealing tests for my domain. And then I can write one (possibly long running) integration test to prove that my adaptor correctly interacts with the external api.
In short, everything gets easier.
Having said this, all is relative and my statement that I should only mock my own code is a sound bite that's overly broad.
If I'm queen and I get to give out dispensations, I'd allow these:
1) For reliable, simple and fast external libraries, don't mock at all. If you need the library in your test just instantiate it and use it. I mean, I wouldn't mock 'String', would I?
2) For reliable and simple libraries that are slow, I'm inclined to directly mock them. If the interface is simple enough so that my mock is cheap, why not?
3) At the first sign of resistance, wrap the external library in a adaptor and mock my adaptor in my tests.
What do you think?
I'm on the stinkin' waiting list for RubyConf; I'm looking forward to getting lucky and being able to hear your talk in person.
Thanks Sandi, you wrote the words i could not write but only feel as this is not good to have the 3thrd partyl libs so tight coupled....please let me quote you in my advice to my team.
I've just bought your book...i'm looking forward to read it..cover2cover.
I loved this talk! Great contribution! I would love to ear you talking about inheritance, and about "Inheritance and Active Record".
"Inheritance is Overrated" is a common saying, but I bet it shouldn't be used to justify bad design decisions... Maybe this topic could be properly approached by you one day.
I have been quietly working on a book, 'Practical Object Oriented Design with Ruby', known affectionately as #poodr. After my goruco talk last Saturday, well, I guess it's not so quiet any longer.
The book is about half done and it'll be on Safari in the next couple of weeks. It's like the SOLID talk, only more so. My LESS talk at this years goruco came directly from the book. Video of the new talk will be online in the next couple of weeks, the slides are available on heroku right now.
I'll post an update here when the book and the video are available.
And, finally, thanks for your comment. I love design but I'm the worlds slowest writer/presentation creator; it involves a lot of head-banging for me. Feedback like yours tells me it's all worthwhile.
thanks for the link. I didn't know you presented this year as well!
I can't wait for the video and the book. my expectations are really high but no pressure (-:
my advice for the book - - real life examples, just like your talk (we already know this) - get it reviewed by many people as possible - create an online site / platform for people to discuss the different designs in the book, so it will be more dynamic and fun.
it must be really hard to write a good book about design, but based on your presentation I am waiting for a delicious read.
Sandi, I just watched your presentation, "SOLID Object-Oriented Design", at GoRuCo 2009. I'm must say that I'm truly embarrassed because it was a great talk and you did an awesome job. Next, I look forward to reading your forthcoming book because many projects that I have worked on may or may not do TDD. Furthermore, most projects that I have worked on didn't address the design aspects of crafting software systems. Thus, I'm very excited to hear about your book which will talk about TDD, design, and Ruby.
I enjoyed the talk very much. Got any more or recommended ones? :)
ReplyDeleteHey, Michal! It's great to hear from you.
ReplyDeleteI can really recommend the Nat Pryce and Steve Freeman talk on InfoQ, Mock Roles Not Object States.
If you get a chance to watch it, I'd be interested in your opinion...
Sandi,
ReplyDeleteI've watched the talk a few times now. You did a fantastic job.
Mark
I'm new to ruby and OOP - your talk accelerated understanding - I wish there were an entire series of this kind of presentation. Seeing the code made ALL the difference.
ReplyDeleteThanks!!
Hi Sandi. I just saw the video of your SOLID talk and really enjoyed it. (BTW, I'm doing a SOLID Ruby at RubyConf, but it goes a slightly different direction than yours).
ReplyDeleteBut, I have a question. In passing you mentioned that you only mock your own code, not code belonging to others. I would love to hear you elaborate on reasons for this.
Thanks.
-- Jim Weirich
Jim,
ReplyDeleteOne mocking hole I repeatedly dig and then must climb out of involves testing across the boundary where my code interacts with an external api.
My goal is to use testing to make my coding more productive and to use mocking to make my testing more productive. In dealing with external libraries I kept failing at this; my testing turned into a high maintenance nightmare that cost more than it returned. I would try to mock the external api but I always ended up writing a lot of fragile, non-intention revealing, test polluting code that wasn't quite right.
I felt stupid and inarticulate about this issue and then I read the excellent chapter on Building on Third-Party Code in Steve Freeman and Nat Pryce's book Growing Object-Oriented Software, Guided by Tests.
Ah ha. The lightbulb comes on. The idea that difficulty in writing tests reveals a design problem that should be listened to is exactly right in my case.
Their suggestion to write an adaptor that exposes only the relevant parts of the external api has many advantages. It lets me simplify the interface as far as MY application is concerned. It gives me a level of indirection that allows me to easily swap to a different external library. I can mock my own adaptor and thus have very clear, intention revealing tests for my domain. And then I can write one (possibly long running) integration test to prove that my adaptor correctly interacts with the external api.
In short, everything gets easier.
Having said this, all is relative and my statement that I should only mock my own code is a sound bite that's overly broad.
If I'm queen and I get to give out dispensations, I'd allow these:
1) For reliable, simple and fast external libraries, don't mock at all. If you need the library in your test just instantiate it and use it. I mean, I wouldn't mock 'String', would I?
2) For reliable and simple libraries that are slow, I'm inclined to directly mock them. If the interface is simple enough so that my mock is cheap, why not?
3) At the first sign of resistance, wrap the external library in a adaptor and mock my adaptor in my tests.
What do you think?
I'm on the stinkin' waiting list for RubyConf; I'm looking forward to getting lucky and being able to hear your talk in person.
Thanks Sandi, you wrote the words i could not write but only feel as this is not good to have the 3thrd partyl libs so tight coupled....please let me quote you in my advice to my team.
DeleteI've just bought your book...i'm looking forward to read it..cover2cover.
Regards,
jr00n
I'm interested in the relation between TDD and SOLID principle.
ReplyDeleteI'm writing a short paper about this and would you like to have your feedback.
http://blogs.ugidotnet.org/luKa/
I loved this talk! Great contribution!
ReplyDeleteI would love to ear you talking about inheritance, and about "Inheritance and Active Record".
"Inheritance is Overrated" is a common saying, but I bet it shouldn't be used to justify bad design decisions... Maybe this topic could be properly approached by you one day.
This is the best talk I have ever seen on this topic. the fact that you used a real life example made a big difference.
ReplyDeleteI am reading 'Design Patterns in Ruby' and love it as well for the same reason.
http://www.amazon.com/Design-Patterns-Ruby-Russ-Olsen/dp/0321490452
Do you have any books/blogs that uses ruby code with real life examples?
Thanks!
Oren,
ReplyDeleteI have been quietly working on a book, 'Practical Object Oriented Design with Ruby', known affectionately as #poodr. After my goruco talk last Saturday, well, I guess it's not so quiet any longer.
The book is about half done and it'll be on Safari in the next couple of weeks. It's like the SOLID talk, only more so. My LESS talk at this years goruco came directly from the book. Video of the new talk will be online in the next couple of weeks, the slides are available on heroku right now.
I'll post an update here when the book and the video are available.
And, finally, thanks for your comment. I love design but I'm the worlds slowest writer/presentation creator; it involves a lot of head-banging for me. Feedback like yours tells me it's all worthwhile.
thanks for the link. I didn't know you presented this year as well!
ReplyDeleteI can't wait for the video and the book. my expectations are really high but no pressure (-:
my advice for the book -
- real life examples, just like your talk (we already know this)
- get it reviewed by many people as possible
- create an online site / platform for people to discuss the different designs in the book, so it will be more dynamic and fun.
it must be really hard to write a good book about design, but based on your presentation I am waiting for a delicious read.
thanks again.
Sandi, I just watched your presentation, "SOLID Object-Oriented Design", at GoRuCo 2009. I'm must say that I'm truly embarrassed because it was a great talk and you did an awesome job. Next, I look forward to reading your forthcoming book because many projects that I have worked on may or may not do TDD. Furthermore, most projects that I have worked on didn't address the design aspects of crafting software systems. Thus, I'm very excited to hear about your book which will talk about TDD, design, and Ruby.
ReplyDelete