Unit tests and destructive methods

D

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
 
T

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
 
E

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.
 
A

Alex Young

darren said:
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.
 
D

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top