Tests for the line-buffered reader added in 7b1ff38 were subtly
dependent on the execution environment due to differing end-of-line
markers on Windows and Unix-based systems.
Because StreamReader discards all newlines when reading line-by-line,
LineBufferedReader used a StringBuilder to patch the peeked lines
back together with the remaining contents of the file being read.
As StringBuilder.AppendLine uses the environment-specific newline
delimiter, the delimiters after the peeked-but-unconsumed lines can
therefore be substituted by the platform-specific variants, causing
the test failures due to the overly-simplified way they were written.
Reformulate the test to avoid such issues from resurfacing again
by splitting lines by \r or \n and then testing each line individually.
Additionally remove all raw literals in favour of explicitly mixing
various line delimiter character sequences for additional coverage.
Add a line-buffered reader decorator operating on StreamReader
instances. The decorator has two main operations - PeekLine(), which
allows to see the next line in the stream without consuming it,
ReadLine(), which consumes and returns the next line in the stream, and
ReadToEnd() which reads all the remaining text in the stream (including
the unconsumed peeked line). Peeking line-per-line uses an internal
queue of lines that have been read ahead from the underlying stream.
The addition of the line-buffered reader is a workaround solution to
a problem with decoding. At current selecting a decoder works by
irreversibly reading the first line from the stream and looking for
a magic string that indicates the type of decoder to use.
It might however be possible for a file to be valid in format, just
missing a header. In such a case a lack of a line-buffered reader makes
it impossible to reparse the content of that first line. Introducing it
will however allow to peek the first line for magic first.
- If magic is found in the first line, GetDecoder() will peek it and
use it to return the correct Decoder instance. Note that in the case
of JsonBeatmapDecoder the magic is the opening JSON object brace,
and therefore must not be consumed.
- If magic is not found, the fallback decoder will be able to consume
it using ReadLine() in Decode().
This commit additionally contains basic unit tests for the reader.
Suggested-by: Aergwyn <aergwyn@t-online.de>
Bartłomiej Dach