Hi --

On Sat, 2 Aug 2008, Phlip wrote:

> David A. Black wrote:
>
>>> - live users
>>> - random numbers
>>> - hardware - networks, robots, tape drives, the clock, etc
>>> - system errors
>>> 
>>> If your B object is not on the list, you should not mock it.
>> 
>> I wouldn't narrow it down that strictly. It can depend on the purpose
>> of the test, as well as the profile of the thing you're mocking.
>
> You can also avoid mocking the clock by setting a time to 2.minutes.ago, for 
> example.

I've had the experience, as have others I imagine, of putting a
future date in a fixture and then, six months later, wondering why my
test wasn't passing... so I'm all for "ago" and friends :-)

> (And "hardware" covers "profile". We don't care if B takes a trillion clock 
> cycles, on a magic CPU that can run them all instantly.)
>
> However, some teams go mock-crazy (even those subjected to high-end 
> consultants), and mock everything for no reason. Don't do that!

It's all about doing it for a reason; I'm just adding to the list.


David

-- 
Rails training from David A. Black and Ruby Power and Light:
  *  Advancing With Rails    August 18-21    Edison, NJ
  * Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!