DUnitX
DUnitX copied to clipboard
Add some file-related assertion
Adding some assertions allowing us to test wether files AreEqual
or AreNotEqual
would be a good improvement for testing file processing procedures.
Here is an example of overloads that could be implemented : http://www.nunit.org/index.php?p=fileAssert&r=2.5
I personally like the filenames and streams overloads.
How would the file comparison done? I like the idea.
What about comparing MD5 hashes? Delphi now has a System.hash
unit with classes for MD5 and SHA-1 hashes generation. They only take Strings as inputs though.
I posted a question regarding hash generation against entire files here
I'm open to any other way to do it. I just think performance should be a concern in a unit test execution context.
UPDATE : It's important to know that System.Hash
doc is a new unit introduced with XE8. So maybe that would make those assertions only compatible with XE8+
I'll accept a PR wth a DUnitX.FileAssert unit, hook it up in the same way as DUnitX.Assert is hooked up in TDUnitX.Create - will need ifdefs if you use something not available in earlier versions of delphi.
I'm actually working on this now. I was looking at the System.Hash and unfortunately it does not have a procedure to hash a file. Everything is done based on string or TBytes, meaning that the entire file would have to be loaded into memory and thus negating most of the benefits versus just doing a memcompare of strings. I am going to look at LockBox via IFDEFS possibly and/or leave the hash functionality as plug-in-able for other solutions people may want to add. I would like it to work well on super huge files, as well as your typical size XML, flat files, etc. I know giant files would probably not be the norm, but no reason not to try.
On another note, I'm adding the ability to point to a FixtureData folder that can hold files that the FileAssert object will let you compare to making it easy to create, edit, and version control the "expected" file data.
Hopefully done in the next day or so and will update my existing PR with the changes.
No point in comparing hashes. Generating the hash would involve reading the whole file. So you could do a byte by byte comparison reading both files at the same time. I would check the size first as it's an easy failure.
The only point to a hash would be to compare a generated file to a hash as an assert.
Glad you said that - I was thinking the same thing, but thought maybe I was missing something. My comparison is currently using 4k blocks and does do a size check to short circuit if different.