On python the test case is:

Test.assert_equals(knapsack(100, ((11.2, 7.4),
(25.6, 17.8),
(51.0, 41.2),
(23.9, 15.6),
(27.8, 19.0))), [2, 1, 1, 0, 0])

But if we are beeing "bad at math" and always getting the bigger value object that fits on the bag we should end up with:
[1,0,1,0,1]

Because we get the object with 41.2 (left with 49 on the bag) than the 19.0 (left with 21.2 on the bag), the objects with values 17.8 and 15.6 are too big for the room left on the bag and thus the object 7.4 fits once (leaving 10 on the bag)

Am I proceeding worng with this?

I must say I disagree with some of the Java tests.

On two of them:
testMultipleBitsPerDotHandling(MorseCodeDecoderTest) ---- Passed: 111
testExtraZerosHandling(MorseCodeDecoderTest) ---- Passed: 01110

The correct response should be to interpret it as a single dot ".", i.e. the letter "E", this is not a sensible test since the letter "S" is coded "..." and with the passed string as argument one could interpret as the letter "S" and rate of transmission = 1 (which my algorithm does).

Am I missing something? I am sorry if I am not correct and I hope someone can show me. But it doesn't seem to me as there were any restriction to something like "Rate is always greater than 1"

how about "fruitBasket" or just "basket"? Even "groceries" or "fruits"...

Yes in the test cases they are indeed correct. I meant on the test cases provided as default under "Your Test Cases:".
I know everyone can change these. I was just pointing out that typo.

The tests are in the wrong order providing a wrong feedback:

The API is: assertEquals(expected, actual)

and in this kata it is as: assertArrayEquals(FruitGuy.removeRotten(rotten),expected);

so just change the order of the parameters passed and it will be correct...

Minor issue ;)