I'll try. I think mocking the file system and other third party, low abstraction stuffs can lead brittle tests and duplications. For example we want to store certificate files in pem format in the file system. Mocking out the fs would look like this: file = mock('file') File.should_receive(:open).with("filename", "w").and_yield(file) file.should_receive(:write).with("pem content of the cert") I don't know ruby too well, so don't know how many different ways I can write some content into a file, but I suspect there are lot. E.g. if I change the "write" to "puts" the test will fail, even if the functionality is still working. That's why it is brittle. There are also some duplication between the test and the production code, because both has the very same structure. Introducing a CertificateStore as a dependency with a more abstract interface solves this problem and simplifies the test as well. cert_store.should_receive(:store_cert).with(certificate) I'm no longer passing the content as a string but as certificate object, and I don't care about the low level details of the storing mechanism. As a matter of fact the storage may store the cert in an other location than the file system, and the client won't care. Then the question is, how do I test the certificate store? And this is the point where I would switch from mocking to integration test. Because I want to be sure that I understood the file system api correctly, and it writes the file physically to the disk. The previous test didn't provide this confidence. Using an inmemory file system to speed up the test is ok imho, but there is a risk of course that it behaves differently than the real one. Personally I wouldn't use in memory file system in a test like this. On Wed, Dec 4, 2013 at 11:31 AM, Frank Shearar <frank.shearar@gmail.com>wrote:
Can you give an example of what you mean?
Being about to stub out the file system, or the clock, seem like extremely useful things to do. (See https://github.com/defunkt/fakefs for instance.)
frank