FileAssert "String like" assertions on file content

[joel-costigliola]

New File assertions (inspired by StringAssert) :

assertThat(actualFile).startsWith("<xml");
assertThat(actualFile).endsWith("xml>");
assertThat(actualFile).contains("Hello");
assertThat(actualFile).matches("*Hello*");

Error messages should mention the charset used to perform comparison.

[olim7t]

I've started working on this issue.

A trivial implementation is to load the contents of the file in a string and delegate to the existing Strings methods. I think this is reasonable for a start (in my experience, test-generated text files tend to remain small), provided that:

• the Javadoc clearly mentions that
• the failure messages are adapted. They currently mention the searched string (the file's contents in this case); even if 4Kb is a small file, that makes a long error message...

But it could also be interesting to provide more efficient versions for large files:

• startsWith is trivial
• endsWith can read from the end of the file but it needs to compare bytes
• contains can apply a string searching algorithm on a Reader or an InputStream.

hasLineContaining and hasLineMatching also sound like a good idea.

[joel-costigliola]

I would go the second option because displaying the whole file content in the error message makes it unusable.

hasLineContaining and hasLineMatching are worthy additions, if I understand well your idea it would require a LineIndex class with atLine static method to write stuff like

assertThat(file).hasLineContaining("content", atLine(17));

or to avoid repeating Line :

assertThat(file).hasContent("content", atLine(17));

For regexp matching :

assertThat(file).hasContentMatching("content", atLine(17));

WDYT ?

Finally Assertions class should also have a static atLine method delegating to LineIndex to offer a single entry point to all Fest features (much like Index.atIndex).

[olim7t]

Mmm, I think I'd still like a detailed message if the file is small enough. I was thinking of delegating to Strings for small files (say, < 1Kb) and fallback to another implementation for larger files. But maybe that's a bit overkill...

For line-related assertions, I hadn't thought of specifying the line number (it was meant as 'has at least one line containing / matching xxx'), but that's a good idea too, both can coexist.

[joel-costigliola]

I personally would rather have an error message mentioning the file absolute path, it makes it easy to open if the user wants to check the file content. Moreover it makes it clear we are doing file assertions and not string ones.

The first idea that crossed my mind for the error message is :

File '/path/to/file' does not contain <'expected text'>.

Your hasLineContaining assertion is a little bit confusing to me, what would be the difference with contains assertions ?

To keep this issue small enough, let's move "line" assertions in another issue (if you don't mind).