Add new shouldContainLineWithString assertion

[igorwojda]

Check if the file contains a given string within any of its lines.
Name is to be decided, but something like:

file shouldContainLineContainingString "abc"
file shouldContainLineWithString "abc"

Something like this:

infix fun File.shouldLineShouldContainString(string: String) =
    this.should("The file '${this.absolutePath}' should have a line containing string \"$string\", but does not") {
        readLines().any { it.contains(string) }
    }

[MarkusAmshove]

file shouldContainLineContainingString "abc"
file shouldContainLineWithString "abc"

or shouldHaveLineContaining sounds good for me :-)

[priyaaank]

If no one else is working on this operator, I'd like to get started on it. Before I do, want to make sure if there is any opinion around the implementation or approach. I should have a PR ready in few days otherwise.

[MarkusAmshove]

If no one else is working on this operator, I'd like to get started on it. Before I do, want to make sure if there is any opinion around the implementation or approach. I should have a PR ready in few days otherwise.

You can give it a shot!

Implementation wise I think there should be one assertion with one parameter, the line that should be within the file. That assertion uses default charset and System.lineseparator.

Charset and line separator should be optional parameters to either the one assertion or an overload, you're free to decide here :-)

[priyaaank]

Thanks, will keep that in mind. The key aspect I want to confirm is the approach to read the file. It is possible to stream it, however assertions will require special logic for reading. For instance if test_string length is 100 and file content is 10 lines each containing 20 chars, I need to load up 200 chars in memory worst case, to ensure any leading or preceding matches are done. But this is efficient that it can handle large files. The alternate is to load up the content completely but in that case, there is a chance, that it may result in a OOM because of the content size.

Given this is used for testing primarily, is it safe to assume that content can be completely loaded instead of partially? let me know what you think about that.

[MarkusAmshove]

My approach would be to load a file completely and wait for someone getting a problem with files that are too large, because I agree that most files would fit into memory.

For files not fitting in memory, a user can still stream the file by hand and use a different assertion on the sequence. They might already be careful when asserting file content because they treat their files different in production code.
If the use case comes up a lot we can add an assertion which streams the file

[priyaaank]

Sounds like a reasonable approach to create this operator. I'll come back when I have something in place. Thanks

[MarkusAmshove]

Will be done with 1.69 through #204 🥳