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
···
--
darren kirby :: Part of the problem since 1976 :: http://badcomputer.org
"...the number of UNIX installations has grown to 10, with more expected..."
- Dennis Ritchie and Ken Thompson, June 1972
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 8/15/07, darren kirby <bulliver@badcomputer.org> wrote:
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.
···
On Aug 15, 2007, at 14:43, darren kirby wrote:
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?
--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars
darren kirby wrote:
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.
···
--
Alex
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 :: Part of the problem since 1976 :: http://badcomputer.org
"...the number of UNIX installations has grown to 10, with more expected..."
- Dennis Ritchie and Ken Thompson, June 1972