The Devver Blog

A Boulder startup improving the way developers work.

Archive for August 2009

Devver is headed to Lone Star Ruby Conf!

Our very own Dan Mayer will be at Lone Star Ruby Conf Friday and Saturday! Be sure to talk to Dan about Devver, testing, or anything else!

Written by Ben

August 27, 2009 at 9:37 pm

Posted in Uncategorized

Tagged with

Unit Testing Filesystem Interaction

Like most Rubyists, I write unit tests to verify the non-trivial parts of my code. I also try to use mocks and stubs to stub out interactions with systems external to my code, like network services.

For the most part, this works fine. But I’ve always struggled to find a good way to test interaction with the filesystem (which can often be non-trivial and therefore should be tested). On the one hand, the filesystem could be considered “external” and mocked out. But on the other hand, the filesystem is accessible when the tests run. In this way, the filesystem is sort of like a local database – it could be mocked out, but it doesn’t have to be, and there are tradeoffs to both approaches.

Over the past year or so, I’ve tried out a few approaches for testing interactions with the filesystem, each of which I’ll explain below. Since none of the approaches met my needs, Avdi and I built a new testing library, which I’ll introduce below.

Mocking the file system.

Sometimes, it is simplest to just mock the interaction with the filesystem. This works well for single calls to methods like




(these examples use Mocha):

File.stubs(:read).returns("file contents")

However, this approach breaks down when you want to test more complex code, which, of course, is the code you’re more likely to want to test thoroughly. For instance, imagine trying to set up mocks/stubs for the following method (which atomically rewrites the contents of a file):

require 'tempfile'

class Rewriter

  def rewrite_file!(target_path)
    backup_path = target_path + '.bak', backup_path) do |outfile| do |infile|
        infile.each_line do |line|
      FileUtils.cp(outfile.path, target_path)
  rescue Exception
    if File.exist?(backup_path), target_path)


Now imagine setting up those same mocks/stubs for each of the five or so tests you’d want to test that method. It gets messy.

Even more importantly, mocking/stubbing out methods ties your tests to a specific implementation. For instance, if you use the above stub (

File.stubs(:read).returns("file contents")

) in your test and then refactor your implementation to use, say,


, you’ll have to update your tests. No good.


MockFS is a library that mocks out the entire filesystem. It allows you write test code like this:

require 'test/unit'
require 'mockfs'

class TestMoveLog < Test::Unit::TestCase

  def test_move_log
    # Set MockFS to use the mock file system
    MockFS.mock = true

    # Fill certain directories
    MockFS.fill_path '/var/log/httpd/'
    MockFS.fill_path '/home/francis/logs/'

    # Create the access log '/var/log/httpd/access_log', File::CREAT ) do |f|
      f.puts "line 1 of the access log"

    # Run the method under test

    # Test that it was moved, along with its contents
    assert( MockFS.file.exist?( '/home/francis/logs/access_log' ) )
    assert( !MockFS.file.exist?( '/var/log/httpd/access_log' ) )
    contents = '/home/francis/logs/access_log' ) do |f|
      f.gets( nil )
    assert_equal( "line 1 of the access log\n", contents )

Although I suspect MockFS would be a great fit for some projects, I ended up running into issues.

First of all, it depends on a library (extensions) that can have strange monkey-patching conflicts with other libraries. For example, compare this:

require 'faker'
puts [].respond_to?(:shuffle) # true

to this:

require 'extensions/all'
require 'faker'
puts [].respond_to?(:shuffle) # false

Secondly, as you’ll notice in the above example, using MockFS requires you to use methods like


instead of just


. This works fine if you’re only testing your own code. However, if your code calls any libraries that use filesystem methods, MockFS won’t work.

(Note: There is a way to mock out the default filesystem methods, but it’s experimental. From the MockFS documentation:

“Reading the testing example above, you may be struck by one thing: Using MockFS requires you to remember to reference it everywhere, making calls such as instead of just As another option, you can use File, FileUtils, and Dir directly, and then in your tests, substitute them by including mockfs/override.rb. I’d recommend using these with caution; substituting these low-level classes can have unpredictable results. “)

All that said, MockFS is probably your best option if you’re only testing your code and you want to mock out files that you can’t actually interact with – for instance, if you need to test that a method reads/writes a file in


(although for the sake of testability, it’s generally good to avoid hardcoding fully-qualified paths in your code).

FakeFS is another library that uses this approach. I haven’t used it personally, but it looks quite nice.

Creating temp files and directories (with Construct)

Besides mocking the filesystem, another option is to have tests interact with actual files and directories on disk. The advantages are that the test code can be simpler to write and you don’t have to use any special filesystem methods.

Of course, as always, you want the test itself to contain all the relevant setup and teardown – you don’t want your tests to depend upon some set of files that have no explicit connection to the test itself (or create files that aren’t cleaned up).

To make this easy, we created a new library called Construct. Construct makes test setup simple by providing helpers to create temporary files and directories. It takes care of the cleanup by automatically deleting the directories and files that are created within the test. And because it creates regular files and directories, you can use plain old Ruby filesystem methods in your code and tests.

To install Construct, simply run:

# gem install devver-construct --source

Using Construct, you can write code like this:

require 'construct'

class ExampleTest < Test::Unit::TestCase
  include Construct::Helpers

  def test_example
    within_construct do |construct| 'alice/rabbithole' do |dir|
        dir.file 'white_rabbit.txt', "I'm late!"
        assert_equal "I'm late!",'white_rabbit.txt')


Let’s look at each line in more detail.

    within_construct do |construct|

When you call


, a temporary directory is created. All files and directories are, by default, created within that temporary directory and the temporary directory is always deleted before



The block argument (


) is a Pathname object with some additional methods (




, which I’ll explain below). You can use this object to get the path to the temporary directory created by Construct and easily create files and directories.

Note that, by default, the working directory is changed to the temp dir within the block provided to


. 'alice/rabbithole' do |dir|

Here we are using the


object to create a new directory within the temp directory. As you can see, you can create nested directories like


in one step. The block argument (


) is again a Pathname object with the same added functionality noted above.

Just like before, the working directory is changed to the newly created directory (in this case,


) within the block.

        dir.file 'white_rabbit.txt', "I'm late!"

Here we use the


object to create a file. In this case, the file will be empty. However, it’s easy to provide file contents using either an optional parameter or the return value of the supplied block:

within_construct do |construct|
  construct.file('foo.txt','Here is some content')
  construct.file('bar.txt') do
  The block will return this string, which will be used as the content.

As a more real-world example, here’s how you could use Construct to start testing the


method we looked at before:

require 'test/unit'
require 'construct'
require 'shoulda'

class RewriterTest < Test::Unit::TestCase
  include Construct::Helpers

  context "#rewrite_file!" do

    should "alter each line in file" do
      within_construct do |c|
        c.file('bar/foo.txt',"a\nb\nc\n")!('bar/foo.txt') do |line|
        assert_equal "A\nB\nC\n",'bar/foo.txt')

    should "not alter file if exception is raised" do
      within_construct do |c|
        c.file('foo.txt', "1\n2\nX\n")
        assert_raises ArgumentError do
!('foo.txt') do |line|
        assert_equal "1\n2\nX\n",'foo.txt')



You can learn more at the project page (both the README and the tests have more examples).

(As an aside, since Construct changes the working directory, it doesn’t play nicely with


. Specifically, if you place a breakpoint within a block, you’ll see the message “No sourcefile available for test/unit/foo_test.rb” and you won’t be able to view the source. If anyone knows an easy way to make


work with


, I’d very much appreciate some help!)


We’ve been moving our filesystem tests over to using Construct and so far have found it to be very useful. How do you test interactions with the filesystem? Do you use one of the above approaches, or something else? Or do you skip testing the filesystem altogether?

Written by Ben

August 25, 2009 at 9:51 am

Posted in Hacking, Testing

Tagged with , ,

Devver is now in public beta!

We’re very happy to announce that today we released our public beta!

This is a big step forward for us and we’re extremely excited about this release. Please try it out and give us feedback on our support site!

Written by Ben

August 17, 2009 at 7:17 pm

Posted in Devver

Tagged with