Groovy random tests:

data: [[], [false, ohbtDHwhhu, -27.88444757461548]] header: false index: false

Kata.toTable(data, header, index) == expected
     |       |     |       |      |  |
     |       |     false   false  |  <table><tbody><tr /><tr><td>false</td><td>ohbtDHwhhu</td><td>-27.88444757461548</td></tr></tbody></table>
     |       |                    false
     |       |                    4 differences (96% similarity)
     |       |                    <table><tbody><tr(><)/(tr)><tr><td>false</td><td>ohbtDHwhhu</td><td>-27.88444757461548</td></tr></tbody></table>
     |       |                    <table><tbody><tr( -)/(--)><tr><td>false</td><td>ohbtDHwhhu</td><td>-27.88444757461548</td></tr></tbody></table>
     |       [[], [false, ohbtDHwhhu, -27.88444757461548]]
     <table><tbody><tr></tr><tr><td>false</td><td>ohbtDHwhhu</td><td>-27.88444757461548</td></tr></tbody></table>

For some reason random tests are generating empty arrays for first element of data, which expects us to produce "<tr />" for it. This is undocumented behaviour, and probably out of range of intended specification. A simple fix would be to avoid generating empty lists altogether.

JavaScript:

• mocha & chai should be used instead of the deprecated Codewars test framework
• JS Node v18 should be enabled

Ruby 3.0 should be enabled, see this to learn how to do it

Please organize the structure of test fixture as following (although it has been mentioned in the attached link, I'm repeated here again)

describe "<This message should describe the categories of test groups inside this block>" do
  it "<A short message describing this test group>" do
    expect(...).to eq(...) #Assertions
    #Or Test.assert_equals(user_response, reference_response)
  end
end

Ruby 3.0 should be enabled, check details here and here.

And if possible update the github list.

(half)moves boundary cases are not tested.

For example:

halfmoves = moves*2 (False)
halfmoves = moves*2-1, active='w' (False)

If there are still empty places left, but no one can win anymore, should I return DRAW or IN PROGRESS?

Could be done at least a bit more interesting if disallowed O(n^2) solutions like this one.

Hi.

I'm not a very mathsy person. Therefore i am confused as to how you calculated x=-108.21, y=-66.64 in your seccond example. I understood the first example of how you got 14 but i am completely lost when you apply it to the 2-dimensional plane. I guess i don't know how to work well with the vectors and radiuses. Perhaps you could point me to some material that i need to learn to understand how to do this calculation or if you could offer any help it would be much appreciated.

Thanks.

Hi, does an enemy die at 0 hp or at <0 hp?

Also, how does the poison stacking work? From the example in the description, it looks like poison deals 3 damaged on the first turn, then increases by 2 after that?

Hi,

I especially didn't like the checks you ask about the en passant moves. To have a valid configuration, those conditions should be met:

• row number
• the targeted place is empty
• there is a pawn of the correct color "ahead"
• the original position of the pawn is empty

All those checks are doable right now.

In a related fashion... why don't you validate that the number of pieces is at least possible?

EDIT: btw, you could add the input in the assertion message for the fixed tests (they are given with the it blocks in the random tests: that's more comfortable for the user)

A duplicate of https://www.codewars.com/kata/yet-another-base-conversion-kata.

Can you just be a normal person and use test.assert_equals instead of wrapping test.expect? The custom message is completely necessary and I don't see how Try debugging. adds to anything.

This is not new at all.