Some quick thoughts on Unit Testing ActivityPub

I'm brutally honest when discussing Test Driven Development - I'm more inclined to telnet into production and accept consequences. The core concept of unit testing is straightforward: feed it good data, expect a true response, and vice versa for bad data. While working on ActivityBot as part of my NLnet-funded project, I'm creating thorough tests for the bot framework, hopeful that they'll prove useful to other similar projects.

Writing tests involves addressing four major classes of issues. To validate an ActivityPub username, we must consider assumptions about its structure: it starts with an @, contains another @, separating user and server parts, the server must be a valid domain name (including non-ASCII Internationalised Domain Names and Emoji domains), and the user part can include various characters. Discovering specifications for these components is challenging.

WebFinger responses, mandatory parts, and the values they can contain also pose questions. Ensuring other ActivityPub servers comprehend messages generated by your project is crucial. Similarly, deciphering follow messages from external servers is a concern. JSON Schemas aid in validating some message types, but scattered specifications complicate the process.

HTTP Signatures present two main challenges: verifying signatures, which requires gathering and replaying signatures, and generating signatures, where only one real method exists for acceptance testing. Effective communication between servers is vital; sending a signed request should be simple and repeatable. However, receiving messages isn't easily automated, demanding control over external servers to send messages, which is feasible with public servers like Mastodon but not always the case.