Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add some file-related assertion #127

Open
m-baumgartner opened this issue Sep 21, 2015 · 6 comments
Open

Add some file-related assertion #127

m-baumgartner opened this issue Sep 21, 2015 · 6 comments

Comments

@m-baumgartner
Copy link

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.

@vincentparrett
Copy link
Member

How would the file comparison done? I like the idea.

@m-baumgartner
Copy link
Author

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+

@vincentparrett
Copy link
Member

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.

@rmcginty
Copy link
Contributor

rmcginty commented May 23, 2016

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.

@rlove
Copy link
Contributor

rlove commented May 24, 2016

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.

@rmcginty
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants