Hello Scott, On Fri, Mar 13, 2009 at 11:59 AM, Scott Taylor <sc...@railsnewbie.com>wrote:
> http://c2.com/cgi/wiki?LawOfDemeter > > Specs are as much of a design tool as a testing tool, and the use of mocks > in your specs show just how ugly the current design is. > > Either write a wrapper around the library which takes care of the method > chaining, or write integration tests against it, stubbing out some low level > detail of the library. Actually, the method 'fetch_new_tweets' is the wrapper. There's another method called 'process_new_tweets', which calls some methods from the Tweet class, including fetch_new_tweets. But I see your point. Testing only the output from this wrapper (integration tests), and not testing the internal actions being done inside Twitter::Search, which Tweet shouldn't know about. So, the ideal would be the Twitter::Search class to provide some ready-to-use wrappers for me, the way I want it. Like the postman and wallet example [1]. But, since it clearly doesn't have all wrappers I need, shouldn't my own class, Tweets, be doing the several wrappers and testing them on my own? Or, there is a better design pattern in this case? [1] http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf Regards, Levy
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
