This post originated from an RSS feed registered with Ruby Buzz
by Obie Fernandez.
Original Post: Mocks versus Stubs Part One
Feed Title: Obie On Rails (Has It Been 9 Years Already?)
Feed URL: http://jroller.com/obie/feed/entries/rss
Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails.
Arrived a little bit late, but having a fun time nonetheless watching Aslak, Michael Granger and Steve Baker defend the ideas behind Behavior-Driven Development (BDD) and the new Rspec library that Dave Astels, Steve and Aslak have been caning. There is a dispute going on because Nathaniel Talbot, author of TestUnit, backed up by Jim Weirich, is presenting worthy objections to the over-use of specification by mocks. I think I can wrap up their argument as unnecessary complexity (introducing these things to Ruby). Now that objection really got interesting when the concept of overuse as a necessary learning step, as expressed by Fowler was brought up. Where does that leave this discussion? Does it make Rspec less interesting? Hmm...
Basically, everyone agrees that this is an area of terrible confusion by the masses. Martin arrived now and is now adding some commentary about mocks vs. stubs. He thinks that a lot of the confusion arose because the original mock papers didn't make a clear difference. There are definite pros and cons with each approach. He also highlighted differences between the process advocated by mockists advocate and classical tdd, so to speak.
I'm loving this discussion. Brian Marick is also an active participant and one of his better points is that we are impoverished with respect to ways of describing these interactions, hence the overloading of terms. Is he calling for an expansion of the domain-terms around TDD?
Bonus points to Aslak and Michael G. for doing real-action sequence diagrams using inverted conference badges as objects with the descending lanyard representing swimlanes. Messages were represented with lots of arm-waving. (heh) The discussion was provoked over the recurring theme of mocks are not stubs.
Brian seems to be questioning who owns the responsibility for verifying the messages sent by the object under test. Is it the mock, or should you be asking the object under test? Another member of the audience compared mocking approaches to design-by-contract.
Fast-forward a bit and we're starting to drive to the crux of this argument. Taking the stockbroker/stockmarket, buy/no-buy interaction that Aslak has been using all along, He describes following a test that should result in a buy, with a test that should result in a no-buy -- by having a stock market mock that first situation with a price that should trigger a buy, then mock the situation (too high a price) to result in a no-buy.
"Ruby leaks internal state like a sieve!" shouts Nathaniel.
Previous Topic
