Email or username:

Password:

Forgot your password?
Johannes Ernst

If you could test just 10 things in the Fediverse on an ongoing basis, what would you test? What's most urgent?

What if you could test 100 things?

(For the non-geeks among us: this is a technical geek / protocol / standards conformance / interoperability question)

@activitypubtestsuite #testing #activitypub

16 comments
Philip Mallegol-Hansen

@J12t @activitypubtestsuite Perhaps an obvious answer but: Which tools out there are ActivityPub standard (federation, not client) compliant (I’d consider that 1 thing, since it’s binary).

In more detail: Which of the different ActivityStreams verb and noun pairs are supported by each tool, split out across client - server, and server - server protocols.

Blake Leonard

@J12t@social.coop @philip@mastodon.mallegolhansen.com @activitypubtestsuite@venera.social I think I'd do it in first class, second class, and no support. First class is, well, first class treatment, like a Note is in Mastodon or an Article for WordPress or WriteFreely. Second class is probably going to be when it's converted into a first class type, like Articles are in Mastodon (afaik) or how Firefish/Akkoma reactions fall back to generic favorites in Mastodon, or when it uses a fallback representation (was it content or summary that's on every object?). No support could be defined as any case where the above doesn't apply, and it crashes (god forbid) or drops/ignores the activity or object entirely.

@J12t@social.coop @philip@mastodon.mallegolhansen.com @activitypubtestsuite@venera.social I think I'd do it in first class, second class, and no support. First class is, well, first class treatment, like a Note is in Mastodon or an Article for WordPress or WriteFreely. Second class is probably going to be when it's converted into a first class type, like Articles are in Mastodon (afaik) or how Firefish/Akkoma reactions fall back to generic favorites in Mastodon, or when it uses a fallback representation (was it

Johannes Ernst

@blake @philip @activitypubtestsuite so you’d have a 3-valued range of support: yes, no, and falling back.

Philip Mallegol-Hansen

@J12t @activitypubtestsuite At the protocol level, I guess I’m thinking: If I send a message of type X, do I get a response that suggests the server accepted it, or not.

Mike Macgirvin (dev)
Not so much ongoing, but for fresh development -

The very first thing to test is the Accept: header. I don't know how many times I've encountered an issue with this on new projects.

The second is array and object support - where some popular project only uses a string. You still need to support arrays and objects without crashing.

A lot of people will disagree with me on this one, but the third should be basic HTML support. I don't care if you throw out iframes or font changes, and I can even (barely) tolerate stripping out images and putting them back in the wrong place or order, but you really make the experience horrible and cause a lot of problems for a lot of people if you throw out the blockquote.
Not so much ongoing, but for fresh development -

The very first thing to test is the Accept: header. I don't know how many times I've encountered an issue with this on new projects.
Tom Brown🏒

@J12t @activitypubtestsuite in my rails app, i am writing a "request" spec to make sure it processes the "Move" command. however, i haven't thought it all the way through yet.

mbrdev

@J12t @activitypubtestsuite surely you only need 1 test, “ItWorks_IsTrue”

Ben Pate 🤘🏻

HTTP signatures
Standard message payloads
Descriptive error messages

@J12t @activitypubtestsuite

Johannes Ernst

@benpate @activitypubtestsuite "Descriptive error messages" is a new one for me. Give an example?

Ben Pate 🤘🏻

Just this: there are tons of ways that an API call can fail, but most Fediverse software just returns something unhelpful, like 500 Internal Server Error.

For production software, that’s probably reasonable, but a well-written test suite should help people debug, not just tell them about the bug.

So if I have a voice, a test suite should really return errors like: “this message was not accepted because it is missing a ‘name’ field.”

@J12t @activitypubtestsuite

Johannes Ernst

@benpate @activitypubtestsuite Right! Somewhere between returning error message payload in HTTP error responses, or logging things to the app's log or the system log, if it is reasonably easy to get at ... I agree!

Go Up