Sandi Metz

I'm certainly no testing expert, so the only a...

2012-02-07T08:01:22.500-05:00

I'm certainly no testing expert, so the only advice I can tender is what I do myself. During tests I try to tell a story about how the interface works, which means illustrating normal behavior, edge behavior and error behavior.

As a simple example, I would test a method that accepts a number between 2 and 999 by creating a test for inputs 1, 2, 999, 1000 and something random in between. Since the output is determined by the input, as long as I test the normal, edge and error cases, I have everything covered.

I'd be interested in other opinions.

And no, thanks for asking, but I hadn't planned on discussing this topic in the book. I was uncertain about covering testing at all, even though (as is probably obvious) it turned out I had more to say about designing tests than I initially imagined. There's a fuzzy line between giving advice about design and giving advice about how to test and while I may have unintentionally ventured across it, I really do mean to leave testing to the experts.

I am enjoying the great book: Practical Object Ori...

2012-02-02T13:46:12.128-05:00

I am enjoying the great book: Practical Object Oriented Design in Ruby. In the testing chapter you have the Interface tests but you have not discussed about testing the semantics of the public interface. How do we go about the output and the arguments that must be provided to the public interface? Will you be discussing this in the book?

NIce article, and yes I dont yet feel it in my bon...

2011-11-04T04:35:36.075-04:00

NIce article, and yes I dont yet feel it in my bones. I guess need to really believe in what i am doing.

2011-11-04T04:33:50.618-04:00

This comment has been removed by the author.

Sandi, I just watched your presentation, "SOL...

2011-10-07T02:50:24.289-04:00

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.

what do rubyists think of DIP (depending on abstra...

2011-09-19T14:21:52.074-04:00

what do rubyists think of DIP (depending on abstractions, not concretions?). Does this apply to Ruby at all?

thanks for the link. I didn't know you present...

2011-06-08T01:03:37.868-04:00

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.

thanks again.

Oren, I have been quietly working on a book, ...

2011-06-07T09:09:49.496-04:00

Oren,

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.

This is the best talk I have ever seen on this top...

2011-06-05T16:53:57.729-04:00

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.

I 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!

I loved this talk! Great contribution! I would lov...

2011-02-12T09:38:14.935-05:00

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'm interested in the relation between TDD and...

2009-12-25T21:35:14.568-05:00

I'm interested in the relation between TDD and SOLID principle.

I'm writing a short paper about this and would you like to have your feedback.

http://blogs.ugidotnet.org/luKa/

Jim, One mocking hole I repeatedly dig and then m...

2009-09-16T08:12:03.688-04:00

Jim,

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.

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.

Hi Sandi. I just saw the video of your SOLID talk...

2009-09-15T19:15:42.389-04:00

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.

Thanks.

-- Jim Weirich

I'm new to ruby and OOP - your talk accelerate...

2009-09-06T05:20:22.312-04:00

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.

Thanks!!

Sandi, I've watched the talk a few times now....

2009-08-20T18:40:41.235-04:00

Sandi,

I've watched the talk a few times now. You did a fantastic job.

Mark

Hey, Michal! It's great to hear from you. I ...

2009-08-19T11:41:03.552-04:00

Hey, Michal! It's great to hear from you.

I 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...

I enjoyed the talk very much. Got any more or reco...

2009-08-13T11:18:15.027-04:00

I enjoyed the talk very much. Got any more or recommended ones? :)

Technically, you're not dealing with a double-...

2009-07-07T15:30:45.522-04:00

Technically, you're not dealing with a double-dispatch problem here. Double dispatch occurs when you have TWO objects which should determine which implementation of a method to call; "double" only depends on the type of its receiver (since it has no arguments).

The "CollideWith" method in the Wikpedia article is a double-dispatch issue because to know which one of the four implementations to call, you need to examine BOTH the type of the asteroid AND and the type the spaceship. C++ (and Java and Ruby) cannot do this on its own; it'll handle a dispatch on the receiving object, but in the general cases, the programmer will have to handle dispatching on the argument.

That being said, the visitor pattern IS a solution for this "double" method, and all the issues raised here are perfectly valid. It's just not technically a double-dispatch issue.

@Aaron, modifying core classes in gems is somethin...

2009-06-20T18:10:02.533-04:00

@Aaron, modifying core classes in gems is something I'm cautious of, but in application code I do it regularly without incident. And don't forget that Ruby gives us the option of modifying an individual object, limiting the potential scope for error even further.

Naming collisions don't come up nearly as ofte...

2009-06-18T12:27:58.563-04:00

Naming collisions don't come up nearly as often as critics suggest.

You could avoid reopening these classes if you wanted to, wrapping them with an object that implements double and then delegates the rest to the original object.

Anyway, the principle at work here is the Open-Closed principle. With the original case-based implementation, if you want to extend the behavior by adding a new type, you would have to modify the original code. Bad.

Nice post :)

Hopefully. I could be wrong. ;-) Here is a simp...

2009-06-17T13:51:40.755-04:00

Hopefully. I could be wrong. ;-)

Here is a simplified implementation of the double dispatch / visitor pattern I typically use:

http://gist.github.com/131378

When it calls "send", it's still examining the type in order to figure out which method to dispatch. IIRC, if I was doing this in Java, I would have to implement a "visit" method for each type I expect to receive. In ruby I cheat by using the class name in the method call, but I'm still asking the object for it's type.

Are we talking about the same thing?

Hmm, I see double-dispatch as avoiding the ...

2009-06-17T13:38:02.620-04:00

Hmm, I see double-dispatch as avoiding the problem of having to examine the type of any object. Are we talking about the same thing? Can you post an example to help me understand what you're saying?

Yes. I use double dispatch heavily for writing vi...

2009-06-17T13:27:51.573-04:00

Yes. I use double dispatch heavily for writing visitors, usually when dealing with ASTs. It would be nice if all objects had an "accept" method for doing this pattern. The only problem is, we have to examine the type, and isn't that what we're trying to avoid?

Smalltalk has a pattern which allows adding this k...

2009-06-17T12:57:39.726-04:00

Smalltalk has a pattern which allows adding this kind of behavior while avoiding method naming collisions.

It's called double-dispatch and basically it involves creating somewhat ugly, but unique, method names by using a namespace (usually something about the original receiver) to make the method names unique.

The technique is used extensively in Smalltalk. It works. I'd like to think we can use it in Ruby to make our code more OO and save us some pain.

Would some form of double-dispatch solve the problem you see?

Name collisions in particular. To me, adding meth...

2009-06-17T12:39:33.591-04:00

Name collisions in particular. To me, adding methods to core classes is like modifying a global variable. It's especially painful when your implementation of "double" doesn't agree with mine. Take your modification of the Array class for example. Array responds to "*", so it may be perfectly reasonable to think that the implementation of Array#double would be "self * 2". Which one is right? IMHO, neither should be added.

Take it one step further. What if I packaged my implementation of Array#double in a gem, and my gem depended on that functionality but you didn't know that! Redefining that method could have unexpected results. A prime example of this problem would be the native YAML gem vs. ActiveSupport's YAML generator. They both extend core classes, and have slightly different API's. Because of that do not play nicely together at all.

Switching on class type seems like a hack because we really should be duck typing, but extending core classes seems dangerous. Unfortunately I don't have a "good" solution. Subclasses or module extension maybe?