mock example

gistfile1.rb

it "should lookup by last_updated for abc files" do
  update_time = Time.now
  # create a location to match this update_time here
  file = double("file")
  file.should_receive(:extension).and_return("abc")
  file.should_receive(:last_update).and_return(update_time)
  MyClass.load_file(file).should == Location.find_by_lookup(update_time)
end

it "should lookup by extension for all other files" do
  # create a location to match the "def" extension here
  file = double("file")
  file.should_receive(:extension).twice.and_return("def")
  file.should_not_receive(:last_update)
  MyClass.load_file(file).should == Location.find_by_lookup("def")
end

Can you include code for the file class and the Location class please? I'm trying to understand how an interface change will cause a failure. Thanks.

hey tall guy, the source is a bit hard to get on this one...sorry. but i do see your point of the should_not_receive & changing last_update to last_updated, and how a compiler could help. You would need to make sure that this behavior is checked in another (should_receive) test. otherwize, it's a bug in the tests.

Ok, though I would be happy with pretend source. So essentially, you need another test to do the "compiler" check. Maybe a better way would be to build that sort of checking into you mocking tool. It seems like ruby has powerful enough introspection to support that, though obviously I couldn't guess at the details.

in Ruby, do DO need tests that test desired behaviors (e.g., use of last_update). that way, if last_update was renamed to last_updated, that test would fail.

The whole point of compilers, interpreters, layers of abstraction are to shorten the semantic distance between our intent and the way the computer thinks of things. In the pure sense, a compiler is a fancy spell checker. Your intent should be expressed thru tests, and then thru code.

Hmm. I like what you are saying Steve. I agree that compilers are glorified spell-checkers, maybe a little more (contract consistency checkers?). You could also think of it as an automatic test generator/runner, for a certain trivial class of tests. But this suggests that code written in Ruby ought to demand more unit tests be written than c# demands. I'm pretty cool with that -- leaning on good tests instead of a compiler sounds great. Does it jive with your comments about 80/20 on test coverage, too many tests are a mistake, etc? Doesn't this suggest that any decent Ruby developer ought to look at the test coverage reached by a c# dev and laugh at their piteousness?

yes, this is why Ruby is "test mad". My comment on 80/20 was more the amount of emphasis on testing behaviors vs emphasis on test coverage (w/ legacy code). When u r doing TDD, like you said, you're getting great test coverage by default. I hope all the language worlds can get together and help learn from each other rather than laugh at piteousness.

Lol, maybe they can all sing kumbaya around a camp fire too. I've got to make some time for Ruby soon, but JS and java both keep getting in the way. Oh well.

I have fond memories of singing kumbaya around a campfire