Good catch! Fixed it.

nitpicks: minor typos in the description

.. start compa[]ring from ..
.. also aster[OI]ds in ..

Done. Thank you.

I don't see why the number of random tests need to be fixed. If there is a specific reason why, would love to know

There are 2 ways to answer to this:

1. Why the number of tests should be random in the first place?
2. In the present case, the variability wasn't problematic, but allowing a random number of tests here or there, and suddenly you see kata popping up with for _ in range(randint(0,100)), and there, it is absolutely awful. So just don't use a random number of random tests, so that other authors don't build meaningless randomt tests.

Empty input is already part of the fixed tests. Adding it in the random test cases won't make a difference

No, that is not enough.

There are 2 ways to... ( x) )

1. fixed tests can be hardcoded in various ways. So the empty input should be present in the random tests
2. generating those in the random tests costs absolutely nohting, as long as the generation is written in a natural way, so if the input is possible, it must be possible in the random tests.

Note that, in cases where some inputs are edge cases, the random test should actually guarantee that those edge cases will be present in the random tests for every run.

Edit: don't forget to add the empty list case in the sample tests, also

Nice.

but not enough x) => answering in the new issue.

Fixed!!!

Sun is no longer a part of the input.

The compairision has to start with the second item, therfore the output size would be 1 less than the input.

• The sample tests now include a test which outputs '='
• I don't see why the number of random tests need to be fixed. If there is a specific reason why, would love to know
• Empty input is already part of the fixed tests. Adding it in the random test cases won't make a difference
• Random test cases now generate tests with only 1 item

Hi,

There are some weird things about the general setup of the task.

• The requirement about the input always starting with the Sun is not logical (at best, it is unnatural)
• The user is told to compare values, hence the ouput should have one less element than the input

The requirement about the Sun being always the first element is a weird mix, at the same time ausing troubles, and trying to avoid some other problems.

Basically, to make things logical:

• the input should contain anything, in any order
• the output should always have one element less, so that it's an actual comparison that is done, between pairs of elements. And if the input is empty, the ouput will also be.

Aside of that:

• there is no sample test outputting '='
• the number of random tests should be fixed
• if the empty input is part of the requirements, the random tests should also generate these from time to time.
• currently, no random input is of length 1 exactly

Cheers

Fixed.

Short and sweet!

All Solar Systems will start with the Sun,

test.assert_equals(jumbled_solar_system([]), [])

This Solar System doesn't start with the Sun.

But it is.

there are 11 animals but Map.of() only goes up to 10 entries. Coincidence ? I think not...

Because I have eluded capture so far...

If caged I would have to eat crow.

These lions are fussy. They don't eat chickens or pandas either.

Absolutely legendary!!!