I’m not sure how to effectively test the vague authorization requirements in the specification other than having the server-specific driver identify a case where its specific authz implementation would not authorize the operation being tested. Absent that, m,y tests currently make some assumptions based on as:Public visibility, recipient fields, and object attribution.
I think writing out these assumptions would be super helpful, actually, because I’ve been scheming on some possible test suite designs and I always come back to many statements spanning multiple layers and requiring a bit of a “mechanical turk” approach. perhaps this could be a topic of discussion at a future CG meeting?
Many developers decide to do whatever is roughly compatible with Mastodon microblogging and assume other servers will do the same. It’s theoretically possible to extend my test suite with an optional category of tests for Mastodon interop, but that’s not my focus at the moment.
it’s not my focus either but that’s the beauty of collaborating on this kind of tooling-- once it’s on a public repo, someone reading this can fork and add those masto interop tests on their own, and PR them in!