On 1/22/08, Kevin Day <kevin@trumpetinc.com> wrote:
Another option would be to have an OOSProvider that could be configured with an instrumentable version for testing (this would be more akin to dependency injection)...  It feels weird to add code to the runtime implementation of a class that forces it to fail...
Any preference? (although I love Brian's idea of using a thumb drive - or maybe even a RAM disk - it's just hard to enforce that stuff in a test suite :-)  )

I understand the weird feeling and I don't have a strong preference.  I think the OOSProvider solution is going to involve more code to achieve the same goal.  If the abstraction isn't needed in the first place, I don't think it's worth the added complexity, meaning adding 4-5 more classes for this test alone.