That's kind of the point. Coding tests are minimal test cases. They're the sort of thing you wish you'd get when someone reports a problem - a distilled reproducible example of something so you can focus on the problem and only the problem.

That's how coding tests should be. Tests with huge blocks of "real world" code that doesn't add anything to the problem you need to solve are much worse.

no programmer is going to write anything useful for you

This is also kind of the point. Coding tests should not produce useful code. They're designed to assess someone's ability without asking them to do proper work. If you end up doing real work in a test situation without getting properly paid for it then you're being scammed.

The problem is often not the test itself, but the failure to do the groundwork to explain why I should take the test. I have a policy that I will never take a coding test before talking to someone from the company - I don't want to waste a few hours of my time on a role I wouldn't accept even if it was offered. I need to talk to the company just to sound out whether the role sounds appropriate, whether the company sounds like somewhere I want to join, and whether or not they're willing to put up with me. If I sound like a reasonable prospect from my resume then the company should be willing to invest 30 minutes on a Zoom call for me to answer their basic questions, and for them answer a few questions I might have too, before I commit to a more indepth series of interviews. If they won't do that then they're not serious about employing me...