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.
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.
12 comments: