Sandi Metz - Magic Tricks of Testing - Ancient City Ruby 2013

[@margaritaville32]

I'm learning Rails testing and this helped a lot. The speaker does a great job explaining not only the "how" but the "why" behind the testing strategies used. Thanks!

[@instarkecontrast]

Sandi Metz @26:28 in the talk you give the caveat that if a collaborator/side effect is cheap/near, that it is "ok" to use the collaborator and validate the side effect directly rather than mocking and expecting an outgoing message. Does that not "bake in" a point of fragility in your tests, because it assumes that the collaborator/side effect will always be cheap/near? What if a future refactoring or feature request increases the cost of using that collaborator and/or pushes that side effect further away? Suddenly that test, with those baked in assumptions/knowledge of the system, is at best slower, and at worst, now proves something that you did not intend (either a true negative, or a false positive). Is it not safer just to isolate by mocking and setting expectations on the outbound message? As you demonstrated in an "Omega Mess" scenario (another great talk, btw.) that Omega Messes don't always stay that way... occasionally they're split or refactored, and part(s) of the mess are moved down the call graph and abstracted behind another boundary. I just seems from a stability point of view, that isolating is the safest bet, rather than relying on tests that straddle the boundary between unit (isolated) and integrated tests. Thoughts?

[@WolfgangRiebeInspiringTheWorld]

always fantastic to be remain positive

[@tr233]

Even if its Ruby the talk is great!