On 19 Oct 2009, at 22:59, Paul Wilson wrote:
> I'm commenting without having seen the presentation, but.... > > I think the point of the Fowler article is more to differentiate > between verifying state (classic TDD) and verifying interactions > (mockist TDD). That is with classic TDD the tests tend to be > concerned with how the code under test changes the system; with > mockist TDD there is more concern with how it interacts with the rest > of the system. I much prefer classic TDD, but that's a whole essay. Hi Paul You have to be careful using the phrase "verifying state", as this can be taken to mean "verifying internal state" (eg instance variables). The way Fowler describes "classist" is still what I consider to be BDD, in the sense of external behaviour. ie, his "state" is what you get out of a real system. His description of "mockist" TDD depends on the size of your classes. Certainly I can think of some code I've written lately where the classes are small enough that if I wrote the specs with mocks, there'd be hundreds of expectations and no useful description of behaviour whatsoever. With larger classes, that may reduce. But his "mockist" description still comes across to me like a description of a plague, like some sort of mock infestation in the specs. Or maybe like some sort of expectation envy. If you feel the need to stub a method on yourself you may be in a high risk group :) I don't know how you feel, Paul - because I haven't read your essay =) But I am currently of the opinions that mocks/expectations should be used selectively where they decrease the fragility, increase the readability, and decrease the time it takes to write specs. (Which sounds alarmingly like another trio of variables you can tune.) Using them without a decision rule is potentially dangerous. > It's probably still useful to call them different things as they tend > to be used differently in mockist tests. You might want to verify > that a service is called with the correct parameters in one tests, but > it muddies the waters to be verifying that in all the others; you'd > use a mock for the first and stubs for the others. I think Jay Fields > explains it better than I can right now. (Tired.) > > http://blog.jayfields.com/2008/01/testing-one-expectation-per- > test.html Unless I get off the train in time to read that, I'm going to have to post blind. I agree with the one-expectation-per-example rule. (I like it because it prevents hidden failures, and makes the specs easier to read.) But I don't think mock or stub *objects* conflict with that. Here's the simplest case of a stub method and an expectation I can think of: class Thing def initialize(object) @object = object end def ask_for_something @object.something # Adding this line would cause a failure: # nil end end describe Thing do before(:each) do @value = mock("value") @object = mock(Object, :something => @value) # Replacing the line above with this would cause a failure: # @object = mock(Object) @thing = Thing.new(@object) end it "should ask for something" do @object.should_receive(:something) @thing.ask_for_something end it "should return the value of something" do @thing.ask_for_something.should == @value end end Note that the first expectation uses the mock as a mock (as traditionally defined) object, but the second uses it as a stub object. What do you call an object that apparently changes its inherent nature (as traditionally defined) between examples in the same description block? Ashley -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran http://aviewfromafar.net/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "NWRUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en -~----------~----~----~----~------~----~------~--~---
