I don't know if anyone else will find this thought useful, but: I think different programmers have different situations, and they often force different sorts of priorities. I feel like a lot of the talk about mocking -- particularly as it hedges into discussions of modeling, design as part of the spec-writing process, LoD, etc -- implicitly assumes you want to spend a certain percentage of your work-week delineating a sensible class design for your application, and embedding those design ideas into your specs. At the risk of sounding like a cowboy coder I'd like to suggest that some situations actually call for more tolerance of chaos than others.
I can think of a few forces that might imply this: - Team size. A bigger team means the code's design has to be more explicit, because of the limits of implicity knowledge team members can get from one another through everyday conversation, etc. - How quickly the business needs change. Designs for medical imaging software are likely to change less quickly than those of a consumer- facing website, which means you might have more or less time to tease out the forces that would lead you to an optimal design. In my case: I work in an small team (4 Rails programmers) making consumer-facing websites, so the team is small and the business needs can turn on a dime. From having been in such an environment for years, I feel like I've learned to write code that is just chaotic enough and yet still works. When I say "just chaotic enough", I mean not prematurely modeling problems I don't have the time to fully understand, but still giving the code enough structure and tests that 1) stupid bugs don't happen and 2) I can easily restructure the code when the time seems right. In such environment, mocking simply gets in my way. If I'm writing, say, a complex sequence of steps involving the posting of a form, various validations, an email getting sent, a link getting clicked, and changes being made in the database, I really don't want to also have to write a series of mocks delineating every underlying call those various controllers are making. At the time I'm writing the spec, I simply don't understand the problem well enough to write good lines about what should be mocked where. In a matter of hours or days I'll probably end up rewriting all of that stuff, and I'd rather not have it in my way. We talk about production code having a maintenance cost: Spec code has a maintenance cost as well. If I can get the same level of logical testing with specs and half the code, by leaving out mocking definitions, then that's what I'm going to do. As an analogy: I live in New York, and I've learned to have semi- compulsive cleaning habits from living in such small places. When you have a tiny room, you notice clutter much more. Then, a few years ago, I moved to a much bigger apartment (though "much bigger" is relative to NYC, of course). At first, I was cleaning just as much, but then I realized that I simply didn't need to. Now sometimes I just leave clutter around, on my bedside table or my kitchen counter. I don't need to spend all my life neatening up. And if I do lose something, I may not find it instantly, but I can spend a little while and look for it. It's got to be somewhere in my apartment, and the whole thing's not even that big. Francis Hwang http://fhwang.net/ _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
