Is it more efficient removing the duplicates this way or is it better with a set

principle of inclusion-exclusion to avoid double counting. very nice

This is a best of both worlds solution, proper message to the user without sacrifycing performance or overview of test cases.

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.

catch errors and fail with a custom error message

correct me if I'm wrong, but I think that's only referring to comparing actual and expected. exceptions? they already fail, they're usually good just as they are.

if user_reply != expected:
    test.fail(f"input was such and such, expected this, but got that")

you should also produce one success in an it if there were no failures if doing the above ^

if no failures happened:
    test.expect(True)

and if you have more than ... say 500 tests, yeah, they're going to need do share an it because the browser code that displays them slows down

for the same reason, you want to avoid test.assert_equals - it generates a message which you're going to want to hide away unless there's a failure.

due to the high number of tests I also suggest breaking the loop on failure or some amount of failures, again, reducing output

(I haven't looked at the test code so I can't say anything about that, and I'm guessing I won't because coprimes? *runs*)

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!

If there are too many test cases, you may also leave the "it" where it is, but then you should catch errors and fail with a custom error message.

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!

You put the "it" at a high level. It should be around a low-level piece of code that performs each single test (or minimal group of related test cases).
Here's an unrelated example:

@test.describe("Random tests")
def _random():
    for _ in range(100):
        xs = test_gen()
        expected = [x for x in xs if x != 0] + [x for x in xs if x == 0]
        check(xs, expected)
        
def check(indata, expected):
    test.it(f"move_zeros({indata!r})")(
        lambda: test.assert_equals(move_zeros(indata), expected)
    )

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!

Time: 6234ms Passed: 50796 Failed: 770 Exit Code: 1

This is all the info outputted to the user on error.
Can you provide more verbose error messages, for instance the arguments for the tests in an "it"?

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?