Pat.<br><br>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.
<br><br>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 :)
<br><br>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 <i>think</i> I isolate services from their dependencies using mocks, I <i>think</i>
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.
<br><br>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 <i>want</i> 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.
<br><br>Like I said, I'll have a proper think and get back to you.<br><br>Cheers,<br><font color="#888888">Dan</font><br><br><div class="gmail_quote">On Dec 15, 2007 7:17 AM, Pat Maddox <<a href="mailto:pergesu@gmail.com">
pergesu@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Dec 8, 2007 4:06 AM, Dan North <
<a href="mailto:tastapod@gmail.com">tastapod@gmail.com</a>> wrote:<br>> I prefer the mantra "mock roles, not objects", in other words, mock things<br>> that have behaviour (services, components, resources, whatever your
<br>> preferred term is) rather than stubbing out domain objects themselves. If<br>> you have to mock domain objects it's usually a smell that your domain<br>> implementation is too tightly coupled to some infrastructure.
<br><br></div>Assuming you could easily write Rails specs using the real domain<br>objects, but not hit the database, would you "never" mock domain<br>objects (where "never" means you deviate only in extraordinary
<br>circumstances)? I'm mostly curious in the interaction between<br>controller and model...if you use real models, then changes to the<br>model code could very well lead to failing controller specs, even<br>though the controller's logic is still correct.
<br><br>What is your opinion on isolating tests? Do you try to test each<br>class in complete isolation, mocking its collaborators? When you use<br>interaction-based tests, do you always leave those in place, or do you<br>
substitute real objects as you implement them (and if so, do your<br>changes move to a more state-based style)? How do you approach<br>specifying different layers within an app? Do you use real<br>implementations if there are lightweight ones available, or do you
<br>mock everything out?<br><br>I realize that's a ton of questions...I'd be very grateful (and<br>impressed!) if you took the time to answer any of them. Also I'd love<br>to hear input from other people as well.
<br><font color="#888888"><br>Pat<br></font></blockquote></div><br>