JUnit question: testing file generators

R

Rhino

I have some classes that generate flat files and I'm trying to think of some
simple way to test to see that they are working correctly.

The classes in question read a ResourceBundle for data, then format that
data and write them out to a flat file with a PrintWriter. The only obvious
method of testing that comes to mind is to create a file that contains what
_should_ be in the generated file, then see if the file which is actually
generated is identical to the expected result. That would fall within the
basic design of JUnit. But I'm not sure how to compare two files within
JUnit even if that is the best way of testing the file generators.

Is there a way to compare two files within JUnit? If not, is there some
other way to test my file generating classes?
 
R

Roedy Green

Is there a way to compare two files within JUnit? If not, is there some
other way to test my file generating classes?

If the files are not too long, you read both in a byte array or string
and compare. If they are very long, compute an Adler checksum on
each. Compare the lengths first. If they differ, you don't even need
to compute the checksum. If the checksums differ, you have a problem.

see http://mindprod.com/jgloss/adler.html
 
L

Luc The Perverse

Roedy Green said:
If the files are not too long, you read both in a byte array or string
and compare. If they are very long, compute an Adler checksum on
each. Compare the lengths first. If they differ, you don't even need
to compute the checksum. If the checksums differ, you have a problem.

see http://mindprod.com/jgloss/adler.html

Whoa! I didn't know Java had native Adler support (in fact I was quite sure
it didn't)

I personally prefer SHA-256 for my checksumming needs. If you are only
doing one file you won't notice a speed difference, and Adler is known to be
weak for small file types. (I realize Roedy specific you should only do
this if you have a long file, but I wanted to make this warning.)
 
A

Andrew McDonagh

Roedy said:
If the files are not too long, you read both in a byte array or string
and compare. If they are very long, compute an Adler checksum on
each. Compare the lengths first. If they differ, you don't even need
to compute the checksum. If the checksums differ, you have a problem.

see http://mindprod.com/jgloss/adler.html

finding out if the files is different is only the beginning. JUnit tests
tell you why they are different as well.

Rhino, there's actually a few add-ons available for JUnit that do
exactly this.

Most provide a new assertfile method.

Junit-addons is probably the dominant player in this field...

http://junit-addons.sourceforge.net/

For its File asserts see...
http://junit-addons.sourceforge.net/junitx/framework/FileAssert.html

assertBinaryEquals(java.io.File expected, java.io.File actual)
//Asserts that two binary files are equal.

assertBinaryEquals(java.lang.String message, java.io.File expected,
java.io.File actual)
// Asserts that two binary files are equal.

assertEquals(java.io.File expected, java.io.File actual)
// Asserts that two files are equal.


assertEquals(java.lang.String message, java.io.File expected,
java.io.File actual)
//Asserts that two files are equal.

assertEquals(java.lang.String message, java.io.Reader expected,
java.io.Reader actual)
//Testing only Asserts that two readers are equal.
 
R

Roedy Green

Whoa! I didn't know Java had native Adler support (in fact I was quite sure
it didn't)
Yes it does. I use it in my "untouch" utility that puts files back to
what they used to be if they have not really changed.
It is very quick.
 

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

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top