Coming to this thread a bit late: I think I'm pretty close to Dan, in practice: I'm not a big fan of fine-grained isolation in writing your tests. The practice seems to me like it would just bug you down. When I'm writing a behavior for a particular thing, such as a controller, I don't want to have to worry about the precise messages that are passed to its collaborators. I try to think in a fairly "black box" manner about it: Presupposing that there's a given document in a database table, when I make an HTTP request that's looking for that document, I should get that document in such-and-such a format. Ideally I wouldn't specify too much whether the controller hits Document.find or Document.find_by_sql or gets it out of some disk cache or gets the data by doing a magical little dance in a faerie circle off in the forest. It's really not my test's problem.
On the other hand, I do think mocking is extremely useful when you're dealing with very externalized services with narrow, rigid interfaces that you can't implicitly test all the time. At work I have to write lots of complex tests around a specific web service, but I don't have a lot of control over it, so I wrote a fairly complex mock for that service. But even then it's a different sort of mock: It's more state- aware than surface-aware, which is part of the point as I see it. Of course, writing those sorts of mocks is much more time-consuming. If you haven't seen it before, Martin Fowler has a pretty good article about the differences in styles: http://martinfowler.com/ articles/mocksArentStubs.html Francis Hwang http://fhwang.net/ On Dec 16, 2007, at 5:59 PM, Dan North wrote: > Pat. > > I'm going to reply by promising to reply. You've asked a ton of > really useful and insightful questions. I can't do them justice > without sitting down and spending a bunch of time thinking about them. > > I'm going to be off the radar for a bit over Christmas - I've had > an insane year and I've promised myself (and my wife) some quiet > time. Your questions have a little star next to them in my gmail > inbox, which means at the very least they'll be ignored less than > the other mail I have to respond to :) > > The one sentence response, though, is that I honestly don't know > (which is why I need to think about it). I can tell you I think I > isolate services from their dependencies using mocks, I think I > never stub domain objects (I definitely never mock them, but > stubbing them is different), I can't say how I test layers because > I think we have a different definition of layers. > > The reason I'm being being so vague is that I usually specify > behaviour from the outside in, starting with the "outermost" > objects (the ones that appear in the scenario steps) and working > inwards as I implement each bit of behaviour. That way I discover > service dependencies that I introduce as mocks, and other domain > objects that become, well, domain objects. Then there are other > little classes that fall out of the mix that seem to make sense as > I go along. I don't usually start out with much more of a strategy > than that. I can't speak as a tester because I'm not one, so I > can't really give you a sensible answer for how isolated my tests > are. I simply don't have tests at that level. At an acceptance > level my scenarios only ever use real objects wired together doing > full end-to-end testing. Sometimes I'll swap in a lighter-weight > implementation (say using an in-memory database rather than a > remote one, or an in-thread Java web container like Jetty rather > than firing up Tomcat), but all the wiring is still the same (say > JDBC or HTTP-over-the-wire). I'm still not entirely sure how this > maps to Rails, but in Java MVC web apps I would want the controller > examples failing if the model's behaviour changed in a particular > way, so I can't think of a reason why I would want fake domain > objects. > > Like I said, I'll have a proper think and get back to you. > > Cheers, > Dan > > On Dec 15, 2007 7:17 AM, Pat Maddox < [EMAIL PROTECTED]> wrote: > On Dec 8, 2007 4:06 AM, Dan North < [EMAIL PROTECTED]> wrote: > > I prefer the mantra "mock roles, not objects", in other words, > mock things > > that have behaviour (services, components, resources, whatever your > > preferred term is) rather than stubbing out domain objects > themselves. If > > you have to mock domain objects it's usually a smell that your > domain > > implementation is too tightly coupled to some infrastructure. > > Assuming you could easily write Rails specs using the real domain > objects, but not hit the database, would you "never" mock domain > objects (where "never" means you deviate only in extraordinary > circumstances)? I'm mostly curious in the interaction between > controller and model...if you use real models, then changes to the > model code could very well lead to failing controller specs, even > though the controller's logic is still correct. > > What is your opinion on isolating tests? Do you try to test each > class in complete isolation, mocking its collaborators? When you use > interaction-based tests, do you always leave those in place, or do you > substitute real objects as you implement them (and if so, do your > changes move to a more state-based style)? How do you approach > specifying different layers within an app? Do you use real > implementations if there are lightweight ones available, or do you > mock everything out? > > I realize that's a ton of questions...I'd be very grateful (and > impressed!) if you took the time to answer any of them. Also I'd love > to hear input from other people as well. > > Pat > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
