• Test.expect should be removed

• Node 12 should be enabled (Refer this and this for more info)

If the requirements for spaces were adequately described or the testing seemed to fit what is described, this would have been a very enjoyable kata.
Otherwise just an exercise in frustration.

.

Random tests sometimes expect results with a trailing space at the very end.

added to description

will make parts as long as possible (API calls can be expensive)

As long as possible is vague. e.g

splitText("4444 1 333 1 4444", 7)

A globally "as long as possible" solution would split it as "4444", "1 333 1", "4444" but a greedy solution would split it as "4444 1", "333 1", "4444". What is the expected answer?

It's not mentioned that input string has words of length at most max (which is assumed to be true, because otherwise it's not possible to perform the task).

The kata said no "indexOf" but it didn't say no "lastIndexOf"!

(Doesn't feel like this should be legal, but good solution nonetheless)

Thanks for your reply and for fixing the tests. It only failed once in each of the two cases that I describe, because in each case, I changed my code immediately. In other words, when it failed for including the spaces, I immediately changed my code to exclude them in general. When it then failed (in only one case) for excluding the space at the end of the final array element, I changed my code so that if the original string ends with a space, then my final array element does, too.

I think the reason why the last test failed in your case is because its randomness caused the text to end with a space. I've fixed it. Have your code (the one that excluded spaces) failed every time you submited or just once?

I like this kind of kata. My only suggestion would be to explain more clearly how spaces should be handled in the output. At first my solution was failing because it included spaces in output, then my last test failed because I excluded the space at the end of the output. This seems inconsistent to me.