Ha-ha, did exactly the same. Extremely confusing desciption

Thanks for explanation!

Hi alanolmo

@Voile is correct about the internal implementation. The Array is too large to print out - Expected: 'true', instead got: 'false' just means that your solution is incorrect for that test case and unfortunately due to the large arrays, I can't print out the test array so that you can see what values were used in that test. It has nothing to do with whether you are printing out anything or not.

Internal solution runs for around 6 seconds, so your aim is to be at least as fast as it.

If your answer is correct, you get true, otherwise you get false.

Hi everyone again!
Thanks a lot for help with this issue, I found that I had a very stupid error in implementation (no idea how it passed sample tests :)).

Now I wonder - is it OK that I have "Array is too large to print out - Expected: 'true', instead got: 'false'" messages? (I'm definatelly not trying to print anything - I run empty function - maybe it's some issue with test? Should I ignore it and continue coding?)
And the second question to people who passed this kata - is it OK that when a try to run empty function it takes 7-8seconds or it's caused somehow by that messages about array size?

The issue with the test suite is now fixed (see issue written by alanolmo).

I just mean that it would be helpful to know at the beginning, that it is about the complexity of the algorithm ;-)

Execution time is 12 seconds (global CW limit).

Also, you seem to mix up the purpose of validity tests and performance tests :)

hmm.. i have two algorithms, one takes about 1380ms and the other only 80ms.. but the random tests still fail.
I think it would be much better to give feedback in the random tests and tell which testcase failed.
With the current test suite it is very unhelpful to figure out what is missing/wrong with the solution. (Unless this is not even about the performance but about writing a new testsuite to debug the code?)

In addition it would be nice to give a hint in the description what is actually the problem to solve (performance) and give clear boundaries for the maximum execution time.

I have added some text to the it block. Thanks for bringing this to my attention, I had no idea about this issue.

I don't know, it's a well-known issue of CW's JS test framework. So the common suggestion is to at least put something non-empty as the descrption string.

Hi Voile

Why would an empty string make any difference as opposed to some text message for that test block when it comes to eating the outputs?

That's because the random tests has this:

it('', function() {
/*...*/

Putting an empty string in Test blocks is a bad bad bad idea, because it eats all the console.log outputs.

I'm getting the same thing.

I copy & pasted my solution out to a html file to test it in Firefox (which I end up doing a lot when I'm stuck). Turns out I can break my solution by feeding it really long arrays (9k+) which some of the other commenters here mentioned were in the random tests, I get too much recursion.

Well, so much for that idea. :/