A fake filesystem. Use it in your tests.

Go to file

Jeff Hodges ddcdfcd04f Suddenly, cp_r works beautifully! This commit now lets us handle the case where a directory is meant to be copied as a subdirectory to the destination path when that path already exists. We also do the appropriate error message when the dest path given is non-existent and so is its parent. Oh, crap, we should probably check that it's a directory that we are merging into.		2009-06-01 03:25:12 -07:00
lib	Suddenly, cp_r works beautifully! This commit now lets us handle the	2009-06-01 03:25:12 -07:00
test	Suddenly, cp_r works beautifully! This commit now lets us handle the	2009-06-01 03:25:12 -07:00
LICENSE	add MIT license	2009-05-29 11:24:36 -07:00
README.markdown	fill out the readme a bit	2009-05-29 11:24:42 -07:00

README.markdown

FakeFS

Mocha is great. But when your library is all about manipulating the filesystem, you really want to test the behavior and not the implementation.

If you're mocking and stubbing every call to FileUtils or File, you're tightly coupling your tests with the implementation.

def test_creates_directory
  FileUtils.expects(:mkdir).with("directory").once
  Library.add "directory"
end

The above test will break if we decide to use mkdir_p in our code. Refactoring code shouldn't necessitate refactoring tests.

With FakeFS:

def test_creates_directory
  Library.add "directory"
  assert File.directory?("directory")
end

Woot.

How is this different than MockFS?

FakeFS provides a test suite and works with symlinks. It's also strictly a test-time dependency: your actual library does not need to use or know about FakeFS.

Authors

Chris Wanstrath [chris@ozmm.org]