Unit tests and destructive methods

[darren kirby]

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

 

[Tim Pease]

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

 

[Eric Hodel]

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?

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.

 

[Alex Young]

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?

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.

 

[darren kirby]

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