Skip to content

Zooid integration tests #2

@staab

Description

@staab

https://github.com/coracle-social/zooid needs to be tested heavily. There are some tests already, but an integration test that really fleshes out access controls from multiple perspectives is necessary.

  • Fix current unit tests
  • Hot reloading of config
  • Feature flags in config (blossom, groups, etc)
  • Blossom access control and upload functionality
  • Make sure /index.html and static serving don't conflict with blossom endpoints
  • Signature stripping
  • Recipient events (zaps and gift wraps)
  • Internal events should not be served (30078 with white lists of d tags, which are created as a way to re-use the event store as a general purpose kv store)
  • Read only events (generated by the relay itself)
  • Write only events (join/leave)
  • Invite link generation - avoid duplicate invite codes
  • Invite code use should grant relay membership
  • Avoid broadcasting stuff that shouldn't be broadcast (requests and subscriptions work differently)
  • Auth-required and restricted happen in the right places
  • Do relay and group member lists automatically include pubkey, self, and role pubkeys
  • Do relay member lists and member update events stay in sync
  • Degenerate cases, multiple conflicting events with the same timestamp, etc
  • Do group events get served when groups are disabled
  • Do group read/write permissions get enforced
  • Test group join and auto join
  • Test group leave and auto leave
  • Do group member lists and member update events stay in sync
  • Group meta creation/editing/deletion
  • Test all management methods
  • Banning should remove from member lists
  • Allowing should un-ban and add to member lists
  • Test group attributes: restricted, private, hidden, closed (see Clarify closed/private, add hidden to nip 29 nostr-protocol/nips#2106)
  • Group deletion should delete all group events
  • Group admin add/remove
  • Group member add/remove (avoid duplicates)
  • Relay admins automatically have group access

The tests don't necessarily need to be organized exactly as listed above. A lot of the different concerns interleave, so testing specific scenarios will make the most sense.

Integration tests should be written in such a way that they're completely agnostic of the codebase itself. In particular, they should go no deeper than the ServeHTTP function, and might make sense to just connect via the network layer.

Metadata

Metadata

Assignees

Labels

Type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions