My 2011 GoRuCo talk, Less - The Path to Better Design, is at Vimeo.
It's mostly about reducing object coupling and is full of example code. If you occasionally find yourself forced into a corner where you have to write case statements that switch on class, have a look, this will help.
Plus, the last two and a half minutes are full of bicycles; what's not to like?
The slides are on Heroku.
Thanks again to all the GoRuCo organizers. The conference is great and is an accurate reflection of their commitment to the community.
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?
ReplyDeleteI'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.
ReplyDeleteAs 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.