Please add fixed tests to the full test suite.

Furthermore please add meaningful assertion messages. You can check out the Rust translations of the Authoring Examples how this can be done.

Yeah, sorry, I've decided to take a break from Codewars for a while, but now I'm mostly back!

So, apologies for deserting this for a while..)

.

Applied my own fixes because original translator appears AWOL.

At least include the sample tests, and maybe a few more with larger numbers.

The assertion messages in Rust only display "left == right", but they don't tell you what left or right is (because usually you're the author of the tests, so you already know). The assertion messages should clarify to the user which one is their result and which one is the expected output.

• How many fixed tests do you think would suffice?
• Could you clarify how do you want the assertion messages to look (like in sample tests?)

Notes:

• Test suite lacks fixed tests
• Tests lack proper assertion messages
• Number of random tests can be bumped up, and the size of the maximum input should be larger than 100. In fact, there's no reason for modulus at all.

Rust translation

Rust translation

Rust (attempt tests only):

error[E0599]: no method named `tuple_windows` found for struct `Map` in the current scope
  --> src/lib.rs:35:10
   |
35 |         .tuple_windows::<(_, _)>()
   |          ^^^^^^^^^^^^^ method not found in `Map<Filter<Enumerate<std::slice::Iter<'_, i32>>, [closure@src/lib.rs:33:17: 33:25]>, [closure@src/lib.rs:34:14: 34:22]>`

That's only the case with test suites like Python, as in those languages the function might be accessible from the solution. (https://docs.codewars.com/languages/python/authoring/#reference-solution)
In Rust you need to declare a function with pub to make it accessible from outside, which isn't the case.

However, for the sake of encapsulation, I will agree that it would make more sense to have the function as part of the tests module.

Reference solution should be inside test function.

Why do we have to write a custom class overriding + method (and only used with MList + list) when a function with arbitrary arguments can be used instead? This adds nothing to the task (and in fact introduces addition irrelevant tasks to the actual task at hand).

[list] + [list] is not tested.

test.expect( issubclass(MList, list), 'list should be inherited in MList' )

Is this actually required? And why isn't it mentioned in the description?