Unit tests and destructive methods

Hello all,

As my flac library approaches 1000 lines of code I decided it would be
prudent
to finally get around to writing some unit tests, which I have done.
Now: I
have created a ‘reference’ flac file with known values, which I then
read to
see if my lib parses it correctly.

That works great for the ‘read’ part of the library, however, I am now
adding
methods which write/rewrite values in the flac file (tags, padding
blocks
etc) making permanent changes in the file, and I am wondering how best
to
write tests for these.

I am thinking that I need to write code which makes a copy of the
reference
file, write the changes, read the copy to ensure the changes were
written
correctly, then delete the copy.

Does this seem reasonable? Is there a better way?

Thanks for consideration,
-d

On 8/15/07, darren kirby [email protected] wrote:

Hello all,

Cheers!

I am thinking that I need to write code which makes a copy of the reference
file, write the changes, read the copy to ensure the changes were written
correctly, then delete the copy.

That is one option. You could also look into mockfs – it’s a Ruby
library that creates a mock file system in memory, and fakes out the
Ruby kernel into using that for File.open, etc.

http://mockfs.rubyforge.org/

Blessings,
TwP

On Aug 15, 2007, at 14:43, darren kirby wrote:

methods which write/rewrite values in the flac file (tags, padding

Does this seem reasonable? Is there a better way?

require ‘fileutils’
require ‘tmpdir’

class FlacTest < Test::Unit::TestCase

def setup
@tempdir = File.join Dir.tmpdir, “flac_test_#{$$}”
FileUtils.mkdir_p @tempdir
end

def teardown
FileUtils.rm_rf @tempdir
end

end

Should get you started.

Thanks everybody. I will play with these suggestions and see what I can
come
up with. I like the idea of just writing the file in memory.

-d

darren kirby wrote:

write tests for these.

I am thinking that I need to write code which makes a copy of the reference
file, write the changes, read the copy to ensure the changes were written
correctly, then delete the copy.

Does this seem reasonable? Is there a better way?
In addition to the other suggestions, you could write to a StringIO
instead of to a File - that way you don’t need to worry about touching
the filesystem at all, and the changes stay in memory.