commit c39b62c1c958f93d0c73159c4bed046c2c8af438
tree 3d8145bcbf516d19ad1dad05dcfaa29260dd01d1
parent f5894c2cfd0b720dcebce52519d6eee87943d7a9
tree 3d8145bcbf516d19ad1dad05dcfaa29260dd01d1
parent f5894c2cfd0b720dcebce52519d6eee87943d7a9
fakefs /
| name | age | message | |
|---|---|---|---|
| |
LICENSE | Fri May 29 11:24:36 -0700 2009 | |
| |
README.markdown | ||
| |
Rakefile | Tue Oct 06 21:32:54 -0700 2009 | |
| |
lib/ | ||
| |
test/ |
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.
Usage
require 'fakefs'
# That's it.
Don't Fake the FS Immediately
require 'fakefs/safe'
FakeFS.activate!
# your code
FakeFS.deactivate!
# or
FakeFS do
# your code
end
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.
Speed?
Installation
Gemcutter
$ gem install fakefs
Rip
$ rip install git://github.com/defunkt/fakefs.git
Contributors
- Chris Wanstrath
- David Reese
- Jeff Hodges
- Jon Yurek
- Matt Freels
- Myles Eftos
- Pat Nakajima
- Rob Sanheim
- Scott Taylor
- Tymon Tobolski
- msassak
Meta
- Code:
git clone git://github.com/defunkt/fakefs.git - Docs: http://defunkt.github.com/fakefs
- Bugs: http://github.com/defunkt/fakefs/issues
- List: http://groups.google.com/group/fakefs
- Test: http://runcoderun.com/defunkt/fakefs
- Gems: http://gemcutter.org/gems/fakefs
- Boss: Chris Wanstrath :: http://github.com/defunkt

