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
