I'm curius whether we're supposed to return each number or print it. I am not aware of any ways to repeatedly return value from a method. As far as i know, once a return statement is executed the program exits from the function. This is why I have choosen to use the "println" method as well.

then you are wong, I believe. ;)

What I was saying is that I bet that the assertion message doesn't show is that returned list is List.of("") while it has to be List.of() or any other version of an empty list. Problem being that the assertion message show the stringified version of the returned list, in which List.of("") will show up in the exact same way than List.of(). So there is definitely no issue here and it's just about foloowing the logic of the problem correctly. ;)

EDIT: just to make things clear: I even checked that the assertions pass correctly returning any of those: List.of(), Arrays.asList() or new ArrayList<>(). So definitely no issue, yeah.

I meant HE is right, I think it should not be difference between an empty List and a Array.toList() as the function is expected to return a List

okay, so closing.

@ArturoJafet: those are in the sample tests, you could have seen it by yourself, actually. ;)

I would suggest to add upper case examples to avoid confusion.

You are right, it is a Type bug with empty arrays. I do this workaround: if result.length == 0 return Arrays.asList()

mmm, my bet: your list isn't empty but contains an empty string (that isn't showing up in the assertion message, so). If that's it, close the issue.

with what input? What are you returning exactly (on the coding side: what statement is it on your side?)

You're right, i'm new to this. Thank you! i've figured out my problem. I'll be more careful next time.

What you say seems a bit unclear for now.

• Afaik, the soluiton is matching perfectly the description. Can you provide a concrete example of wrong delimiter?
• About the "twice" problem, that's sounds rather unlikely to just run into the situation because it would require a randomly generated word to be the exact double from another randomly generated one. Still possible, yes. But considering the number of random tests, that shouldn't even be noticeable.
• ...the randomly generated test cases measures all occurences of the returned strings as substrings in the input text.

-> nope:

TopWords.top3("mhvhdmhvhd mhvhd mhvhd mhvhd mhvhdmhvhd")
    
# here is what my solution is counting in there (I created the random tests):
{mhvhd=3, mhvhdmhvhd=2}

So, doesn't match at all what your saying.

Really sounds like an invalid issue, so closing. If I'm wrong, reopen a fresh one, but this time, do it "right":

Seems you're "rather new" to cw, so here are some general guidelines about the comments:

• Issue: problem in the kata itself (description, wrong tests, wrong internal solution...)
• Suggestions: well, I guess that part is clear
• Question anything else that is related to you having a problem solving a kata -> that's you, currently.

When you post issues:

• provide ALL the useful information:
  • language
  • input
  • outputs (actual expected) when relevant
  • error message when relevant
• check, DOUBLE check that this IS an issue, meaning that the problem is in the kata itself and not in your code. If it's in your code, post rather a question
• if you pass this step, you still have to prove/explain what the issue is (and if you can provide fixes, it's even better)

When/if you post a question: well, most of the above apply too x)

When/if you post code, use proper github markdown, so that it's readable.

cheers

oh, that is actually way simpler than that. The problem is on your side:

Matches should be case-insensitive, and the words in the result should be lowercased.

okay. Can you give me your output on those, please?

I have noticed that the randomly generated test cases measures all occurences of the returned strings as substrings in the input text. So if one the strings i outputed was "mhvhd" and "mhvhdmhvhd" was part of the string generated by the text function it expects that "mhvhd" should be counted twice. The test function isn't working on the same delimeters as the instruction. Atleast this is the case in java.