1

I am creating a JUnitTest test that compares a file that is created with a benchmark file, present in the resources folder in the src folder in Eclipse.

Code

public class CompareFileTest
{
    private static final String TEST_FILENAME = "/resources/CompareFile_Test_Output.xls";

@Test
public void testCompare()
{
    InputStream outputFileInputStream = null;
    BufferedInputStream bufferedInputStream = null;

    File excelOne = new File(StandingsCreationHelper.directoryPath + "CompareFile_Test_Input1.xls");
    File excelTwo = new File(StandingsCreationHelper.directoryPath + "CompareFile_Test_Input1.xls");
    File excelThree = new File(StandingsCreationHelper.directoryPath + "CompareFile_Test_Output.xls");

    CompareFile compareFile = new CompareFile(excelOne, excelTwo, excelThree);

    // The result of the comparison is stored in the excelThree file
    compareFile.compare();

    try
    {
        outputFileInputStream = new FileInputStream(excelThree);
        bufferedInputStream = new BufferedInputStream(outputFileInputStream);

        assertTrue(IOUtils.contentEquals(CompareFileTest.class.getResourceAsStream(TEST_FILENAME), bufferedInputStream));
    }
    catch (Exception e)
    {
        e.printStackTrace();
    }
}
}

However, I get an Assertion Error message, without any details. Since I just created the benchmark file from the compare file operation, both files should be identical.

Thanks in advance!

EDIT: After slim's comments, I used a file diff tool and found that both files are different, although, since they are copies, I am not sure how that happened. Maybe there is a timestamp or something?

Benoit Goderre
  • 527
  • 2
  • 9
  • 25
  • 1
    extract `CompareFileTest.class.getResourceAsStream(TEST_FILENAME)` into a variable and check it's not null. – roby Dec 18 '16 at 23:04
  • @roby It is not null unfortunately. – Benoit Goderre Dec 18 '16 at 23:34
  • Next you could convert both files to String and try assertEquals. You could use `IOUtils.toString(InputStream, Charset)`. – roby Dec 19 '16 at 00:43
  • I'd try debugging through the Commons code. And if this fails, copy it to your own space, and put some logging in, so you can see what the mismatch is and how many characters in it occurs. – Dawood ibn Kareem Dec 19 '16 at 01:49
  • As I am comparing two Excel files, it is quite complicated to debug since the characters are gibberish at best. – Benoit Goderre Dec 19 '16 at 05:10
  • `assertEquals` hides the assertion error message, I'd use `assertThat` instead to figure out what exactly the difference is – Thanos Dec 20 '16 at 16:26
  • try this `StringEscapeUtils.unescapeJava(text)` from Apache Commons Lang maybe there can be hidden characters in your files. – gihan-maduranga Dec 20 '16 at 16:29

2 Answers2

3

IOUtils.contentEquals() does not claim to give you any more information than a boolean "matches or does not match", so you cannot hope to get extra information from that.

If your aim is just to get to the bottom of why these two files are different, you might step away from Java and use other tools to compare the files. For example https://superuser.com/questions/125376/how-do-i-compare-binary-files-in-linux

If your aim is for your jUnit tests to give you more information when the files do not match (for example, the exception could say Expected files to match, but byte 5678 differs [0xAE] vs [0xAF]), you will need to use something other than IOUtils.contentEquals() -- by rolling your own, or by hunting for something appropriate in Comparing text files w/ Junit

Community
  • 1
  • 1
slim
  • 40,215
  • 13
  • 94
  • 127
  • Thank you for the answer! Since I am comparing two Excel files, I am not hoping for detailed error messages of which bytes are incorrect as I will not be able to understand them anyway. My problem is that both files SHOULD match as they are a direct copy of each other and I don't understand why Java returns false for the comparison. – Benoit Goderre Dec 20 '16 at 16:53
  • 1
    Are you absolutely certain that `StandingsCreationHelper.directoryPath + "CompareFile_Test_Output.xls"` and `/resources/CompareFile_Test_Output.xls` refer to the same file? Validate with http://stackoverflow.com/questions/17351043/how-to-get-absolute-path-to-file-in-resources-folder-in-your-project – slim Dec 20 '16 at 17:01
  • They don't point at the same file, but they point at files that are identical. – Benoit Goderre Dec 20 '16 at 17:06
  • 1
    I suggest to you that they are not identical -- unless you can prove they're identical using `diff` etc. -- when two pieces of code, one written by a third party, and one written by yourself, both tell you that they're different, they're probably different! – slim Dec 20 '16 at 17:11
  • Lol, I would normally agree. Here is what I did in details: 1. Run the compareFile.compare(); operation. 2. Copy the output result to the resources folder in Eclipse. 3. Run the contentsEqual function on both files without changing anything after step 2. Both files should be the same, just as different locations. – Benoit Goderre Dec 20 '16 at 17:15
  • 1
    What OS are you on? What does `diff` say (MacOS/Linux/UNIX), or `FC /B` (DOS/Windows) . Once you believe the files are different, you can start working out *why* they are different. – slim Dec 20 '16 at 17:21
  • Thank you for the help! @slim – Benoit Goderre Dec 20 '16 at 18:21
0

I had a similar issue.

I was using JUNIT assertion library Assertions and got the memory address being compared rather than the actual file it seemed.

Instead of comparing the InputStream objects I converted them to byte arrays and compared those. Not an absolute specials, but I dare to claim that if the byte array is identical, then the underlying InputStream and its file have a large chance of being equal.

like this:

 Assertions.assertEquals(
            this.getClass().getResourceAsStream("some_image_or_other_file.ext").readAllBytes(),
            someObject.getSomeObjectInputStream().readAllBytes());

Not sure that this will scale though for larger files. Certainly not OK for complex diffs, but it does the trick for an assertion.

Matthias dirickx
  • 141
  • 2
  • 10