;-)

Also, in the instructions here:

This reader exposes only one method : getChunk()

Returns the following fragment of text from the file it is reading
Returns a string of random size
Returns at least one char
Returns an empty string when finished

I would just get rid of "Returns at least one char" Maybe just have this:

This reader exposes only one method : getChunk()
Returns a fragment of text from the file it is reading as a string.
The fragment can be any length, including 0 (empty string).
If the fragment is an empty string, the reader has reached the end of the file, and will only return an empty string on subsequent calls.

I think I understand why it says it will return at least one char, but I think it means to say, "if doesn't return an empty string, the string will be a minimum of 1 char" which is kind of redundant info and confusing.

but what about this test case:

testX:
{
  text: "A\n\nB",
  words: 2,
  chars: 2,
  lines: 2 // or 3?  If 3, then an "empty line" is a line, and thus test4 in your example should have 1 line.
}

Empty string is a special case which doesn't really make sense in a reader.
But anyhow, that would means nothing, thus :

      test4:
      {
        text: "",
        words: 0,
        chars: 0,
        lines: 0
      }

i do agree this is in conflict with the "Returns at least one char" instruction
(i don't remember if this was in the description i specified 9 years ago or if someone added that line since then)
but defensive programming is always recommended and those values are easily testable

as soon as there is one char, you get a line and a word

      test5:
      {
        text: "A",
        words: 1,
        chars: 1,
        lines: 1
      }

but there is a special weird case, what if the text as chars, but it only contains spaces ?
...
there is no word!

      test6:
      {
        text: " ",
        words: 0,
        chars: 1,
        lines: 1
      },

From the instructions:

This reader expose only one method : getChunk()

Returns the following fragment of text from the file it is reading
Returns a string of random size
Returns at least one char
Returns an empty string when finished

In the instructions, it states that the getChunk function exposed by the reader "Returns at least one char".
One of the test cases, the first chunk received by the parse method is an empty string (so the entire string it was reading must be an empty string), thus making the charCount, wordCount, and lineCount expected to be 0.
Even if it was allowed that the first string received by getChunk was an empty string, there are other tests where there are empty lines that count as a line, so wouldn't an empty string test case still have a lineCount of 1?

Example:

chunk = 'foo\n\nbar'
expected result:
charCount: 6
wordCount: 2
lineCount: 3

and if that's the case, then shouldn't this be true:

chunk = ''
charCount: 0
wordCount: 0
lineCount: 1

Thank you for the reply. :)
Will revise my code

You're not supposed to give a reader argument to DocumentParser.prototype.parse. You're supposed to call the getChunk() method from the reader instance that is already provided to the constructor of the DocumentParser object.
So you can perform these changes :

// replace this
DocumentParser.prototype.parse = function (reader) {
// by this :
DocumentParser.prototype.parse = function () {
// and, each time you want to call the 'getChunk()' method, use this : 
this.reader.getChunk()

And then you can implement and test your solution.

(I let the issue open since it's a strange behavior and most likely truly a bug...)

Is this a bug or did I just misunderstood something?
I tried to console.log the output within parse() and it seems like I get correct char, word, and line counts (on the initial test case: "Once upon a time")

This error shows upon Test (not on submit)

TypeError: Cannot read properties of undefined (reading 'getChunk')
    at DocumentParser.parse (test.js:54:21)
    at Context.<anonymous> (test.js:93:12)
    at process.processImmediate (node:internal/timers:471:21)

Appreciate any feedback :)

Lines are separated with "\n"

Your problem has something to do with the definition of a white space and the behavior of some function...

Closing since it's not an issue related to the kata itself.

Once upon a time.

Invalid lines count!: expected 1 to equal 2

why?
am i missing something ? why should this be 2 lines ?

here is an example https://www.codewars.com/kata/reviews/5286a298f8fc1b7667000c1f/groups/55633cb19b780ca9fb000031

Kata is good, it's great you've made it.
I agree that adding tests for memory limitations is not a trivial thing. So I'll try some ideas, maybe would found how to do that properly ...

That opens up the vulnerability of matching a finite ( and probably limited ) set of inputs to expected outputs.

Really, random tests aren't hard to do if you have a bit of experiende implementing them ( which you don't, I appreciate that ). There are people who can bang them out in five minutes, and one of those will probably do it for you. Just leave this for now.

Or just randomize tests order as a first step?

Actually, it's not hard to figure out the expected values, because the tests are run in order and failed tests tell you which value was expected. So you set up the framework and incrementally run tests, adding one expected value at a time.

You may not like it ( and you clearly don't ), but it's how things have been here for over five years.

Generating meaningless sentences is not a problem, and with a reference solution in the tests, the complexity is low. But you obviously don't feel like doing it, so maybe Josz will do it, he's been considering it on Discord #reviewing.