Modified the Sample Test Cases ✅

@Deantwo I could just put all of the fixed tests into one function called `"Fixed Tests" if you prefer it that way. No problem

I think the OP is concerned with the code, and not test output of assertions themselves. And yes, authors usually have to decide in the trade-off of collapsed test cases looping over many inputs, or explicit test methods for every input. Ideally, both could be combined with generated test cases, which is unfortunately not possible on CW for Groovy (see https://github.com/codewars/runner/issues/301).

My approach is usually to go with separate test methods for short, easy to present inputs and outputs, and looping over many inputs in a signle test method for long inputs (long strings or long arrays), which otherwise make test output bloated.

And the ASCII-artish messages created by Groovy's assert are awful, change my mind.

Fixed ✅

According to the user ejini, assertEquals provides much better information when the test fails.

Source

ejini also strongly suggested to refer to Hobovski's Groovy translation for Even or Odd by suuuzi. here

done

In the Japanese traditional martial arts (...) it is a verbal command to "begin"

Source: https://en.wikipedia.org/w/index.php?title=Hajime

My bad. Thanks for pointing that out!

👍

Hi @Deantwo, in Lua it's in general a good practice to return a table (aka dictionary or map), so local solution = {} creates a new one so that we can store our functions inside it, and return solution makes so that anyone doing require 'solution' receives that table (with the high_and_low function inside).

Ah, you meant that. I didn't see named tests in Python nor JS, so I thought they were not on this kata in general. If you prefer it, you can approve this fork: https://www.codewars.com/kumite/62ebcdba8f8ab4003d2a4d4e?sel=62ebdd4f4b883000572931e8

I don't understand why, both do the same.

The logs give clearly the actual value returned, the expected value as well as the input in case of failed test. The default setup throws a Non implemented error (like it is done frequently in other languages like Rust or C#), just replace the empty set up with return ""; for example, and you will see. If your point is that you would like the input to be displayed clearly for each test, no matter if the test fails or not, indeed it is not really feasible with this framework, it is not designed for that.

Fixed a crash in the testing suite, albeit a very rare one on this kata. Scalatest will crash if it encounters two tests with the same title, so I've just added the test case number to the title to prevent that ever happening.

Most kata's I've seen use the name Sol for the object.

The quotation marks is an oversight, I'll fix it.

Thanks.