<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 23 Nov 2011, at 08:32, Graham Ashton wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">On 23 Nov 2011, at 08:10, Matthew Rudy Jacobs <<a href="mailto:matthewrudyjacobs@gmail.com">matthewrudyjacobs@gmail.com</a>> wrote:</span><br></div><div><br></div><div></div><blockquote type="cite"><div><div><div>You can structure the naming of your tests in an infinite number of ways <span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">but these are the behaviours I'd care about.</span></div></div><div><ol><li>If I don't PUT anything into the box, I GET nothing out.</li>
<li>If I PUT something in the box I GET out the same thing</li><li>If I PUT something in the box and try to GET it multiple times, I always GET the same thing</li><li>If I PUT multiple things into the box, I only ever GET the most recent.</li>
</ol></div>
</div></blockquote><div>Do you mean you'd test all those behaviours, irrespective of how you implement it?</div><div><br></div><div>I only ask as I just test things that I think might not work, in the context of how I've implemented it. i.e. My decisions are informed by my knowledge of the implementation.</div><div><br></div><div>So if we were using attr_* to implement the feature (I realise it's a contrived example) I'd skip the test entirely as I'd just be testing Ruby (which is pointless). If I wrote my own getter and setter and implemented them the same way as attr_* does it, I'd only need to test behaviour 2. Checking 1, 3 and 4 would introduce cruft.</div></div></blockquote><br></div><div>The problem with testing this way is that it doesn't help you refactor. If you were using attr_* ans so didn't right any tests, and then some enterprising soul removes your attr_* line, your test suite (or certainly at least your unit test) will still pass, giving a false positive result.</div><div><br></div><div>Asserting against behaviour means you're free to change the underlying implementation with reassurance that the "API" your object exposes never breaks. Comprehensive tests like those above are the price you pay for the freedom to refactor with impunity.</div><div><br></div><div>Using attr_* as the basis for this kind of discussion is, I suspect, a bit distracting since the behaviour is probably trivial compared to other aspects of most code, but the principles still technically apply I think.</div><div><br></div><div>- James</div><br></body></html>