I've changed the check function I used to instead compare the results directly, and use the test.pass_() or test.fail() functions for the test results, returning booleans to allow me to break the loops / return out of the test functions. I think it definitely makes a difference only seeing like 8-10 error messages on wrong solutions instead of the 50-60k I had before. Thanks for the suggestion @natan !

Due to the sheer number of tests (I think theres about 60000 total, I think you'd be right in that, check if actual == expected in a loop, and if any aren't, fail for that 'it', I did see a significant slow down when i tested the error messages with a blank body. At least for me it only slowed down when i tried to scroll. I'll try implementing this to make it run more smoothly.

I think I've fixed the error messages for both exceptions as well as wrong results, let me know what you think! I really appreciate the feedback!

Oh ok I see! So in the case where I've left the 'it' statements as is, I'm assuming I should basically use a try/catch around each block of tests decorated with test.it, as some of the examples give, and in the catch block, I should probably give the input data and potentially the expected as well? I'm pretty sure try/catch blocks are pretty slow although I'm not sure how true that is. Thanks for the advice and code snippet!

I believe I've added test cases that don't allow the solution you linked to to pass now, thank you very much for bringing this to my attention! Appreciate it!

I'm surprised that all that shows is the time, passed, failed and exit code, I think I've fixed the test cases to at least give the expected and actual, but this is my first time writing test cases. I looked on the forums for help, but all I saw was stuff on the test.describe and test.it. I'm not sure how to handle when theres an exception beyond setting variables during tests and in the case of an exception, use those for the error messages? Please let me know, this is a good suggestion!

I've increased n (as well as the limit since apparently I overlooked a test case going over n) as well as increasing the value of the primes in the strictly prime tests, as well as adding semiprime tests using a list of 50 primes paired up and multiplied. Even with this my reference solution is taking approximately 7 seconds. Any other advice for increasing the difficulty?

Looking at the solutions that were passing before, a lot of the solutions that involved iterating over all i in range(number) and checking for i being a multiple of a list element are failing now. If you have any more suggestions please let me know!

Note taken! Thanks for the feedback! I'll be mindful from now on!

I see! I'll add some test cases with higher values so only semi-optimized solutions pass. Currently the reference solution takes about 7 seconds; if you have more suggestions please let me know!

@Blind4Basics, yes that was the issue! I just fixed it, I really appreciate the help!

I fixed the issue, and please correct me if I'm wrong, but no element of lst ever exceeded 1000. I reviewed my test cases, and it seems the largest I use is 541.

oh I see the issue, I should be writing 2 <= len(lst) <= 25. Thanks! I'll fix that right up! I really appreciate it!

Interesting solution! I've been adding test cases to more fully test edge cases such as lists up to 25, and larger number values, I'd love to see a slightly optimized version of this!