Duplicate issue. Closing.

• Imports should't be preloaded
• New test framework should be used
• test.expect(encode, "encode is not defined") and test.expect(decode, "decode is not defined") tests are pointless, and won't even work in Python
• Error handling tests are very poor
• "Random" tests are not random at all
• "Large" tests are not really large, and they are just as bad as the "random" ones

10 and 100 are both O(1)! The problem has an explicit upper limit so it doesn't make much sense to overengineer the problem. (that said, it would not hurt to use a set)

Wut :O ?

Why checking 100 values when you can only check 10?
Also you should a set when checking if a value is present in a collection, otherwise you walk through the entire array at each check.

Very nice. I still don't understand what stepped ranges are but Im sure googling could figure it out. Although having some sort of example would be nice

Edit: NVM you fixed this I didn't notice

I've rearranged it a couple of times, unfortunately it makes sense to me (obviously), are there any obvious reworks that would make it cleaner.

I've removed the 31st of February unnecessary statement.

I'll be cleaning up some of the assertions in the simpler tests to make them easier to understand (which should cover the code side of the suggestion)

Edit: I've done some rearranging and adding of headers. Hopefully should be a little clearer now?

he's not talking about the code, but about the description (As I said below, the information is spread "all over the place", so it might be useful to rewrite it in a more structured fashion)

In regards to the test assertions, do you have any suggestions to make it more readable?

The issue with changing the assertions is, I could update it to compare each line in the output, but in the case of issues in multiple fields it would not be clear (only the first failure would be rendered). It would also muddy the water as to the output format as it would look like a list more than a string output.

Edit: Have added specific formatting tests, and updated the tests that are expecting a single field to be outputted correctly to only assert that line. The random tests will still use the old compare everything assertion.

Could you be more specific in regards to which of Blind4Basics issues are coming up for you as well? Each of the issues has been marked as resolved so the same issues should not be possible.

Everything Blind4Basics said has come up for me as well as the output of 'minute 1 15 16 17 0 10 20 30 40 50\nhour 0\nday of month 1\nmonth 1\nday of week 1' should equal 'minute 0 1 10 15 16 17 20 30 40 50\nhour 0\nday of month 1\nmonth 1\nday of week 1' is TERRIBLE to read and Im sure you could come up with a better way of solving it.

Please make the directions better. This line isn't necessary and is misleading as it is one of two exapmples According to crontab.guru 5 4 31 2 * would occur “At 04:05 on day-of-month 31 in February.” And overall they're just hard to read

sounds good, yep.

:)

sounds like this part has been handled (note, tho, that the information is spread "all over the place", so a reorganization might be a good idea)

both random choices should now differ.