There's also no reason to print on each test iteration. Feedback is really only necessary when a test fails.

Please also expand the assertion messages for the sample_tests, remove the print line and add the input to the assertion message.

My apologies. I totally forgot I attempted to do this two years ago. I hope the revision meets the expectations.

These should all (besides random tests) be fixed now thanks to mjpeters' fork. (?) Please open new issues for any new problems found.

I've created a fork that addresses all of these issues except for the randomised tests, since none of the other translations have randomised tests either.

And another issue:

• The sample tests do nothing. They instead comprise the simulator and a small test for the simulator. 🤦‍♂️

Marking Resolved as of Jauttaro Coudjau.

added to the description

Rust fixed in this fork

Other languages do not have such cases in fixed and random tests (Dart && PowerShell already handled in editor), closing

Check what happens when you try to round following numbers: 2.5, 3.5, 4.5, 5.5.

I'm sorry I don't understand what you are both saying, about nearing to the "nearest even integer" (it's probably because of my lack of mathematical knowledge).

In Python, as far as I know, if you try to round let's say 4.6, it will give you 5, which is the "nearest integer" (not even), just like it's specified in the statement.

What am I missing?

Well, exactly this is the case when &Vec<Vec<>> is better. I've started with

type Matrix = Vec<Vec<i32>>;

but then decided not to overcomplicate the code. We have a matrix type here, represented with Vec<Vec<>>, not an arbitrary slice of Vecs.

Also, there's nothing wrong with negatives in matrix, they should be allowed, but I don't see any actual reason to test them.

Oh, about that (I guess we're getting nitpicky): you never use negative numbers, so the type should probably be a u32 instead of i32. Also, I believe it's good form to use &[&Vec...] instead of &Vec<Vec...> as the parameter type, though that is obviously more for real world applications instead of kata, where the type is always a Vec.

Added better diagnostic messages.

Fixed the incorrect function definition in solution setup.

Your assertions need proper messages to communicate to the user what the input and what their output was. You can refer to the tests in this kata for a comprehensive breakdown of recommended authoring practices in Rust.

I see you've authored a few Rust translations; may I suggest that you go back and apply this fix to all of them?

On a different note, the description is terribly JS/Python-centric, and could benefit from being made language agnostic (or by structuring properly with language blocks). Maybe you'd like to take that on as part of this translation.

approved.