Service account/guild concept for full e2e testing

[MattIPv4]

Description

This is definitely one of the more "out there" requests, but I think it'd be incredibly awesome if there was a concept of a service account/guild added for testing.

The service account would be a restricted user account, locked to a single guild hidden in the void, that could be automated via the API to send messages etc., simulating a real user using a bot.

The service guild would be the guild that this service account resides in. I'd envision it being incredibly locked down, perhaps not even accessible by a normal user, just the service account and the bot being tested.

Through this, CI e2e testing can be written to properly simulate a Discord user interacting with a slash commands bot.

Why This is Needed

Would be great to be able to properly test the full flow of interacting with a slash commands bot.

Alternatives Considered

Unit testing definitely gets you a lot of the way to validating that your logic is working and generating correct payloads for Discord. Further, a VCR of an old payload from Discord can be used to test the full flow of the bot logic on the bot's end, but there is no way to test against the latest state of Discord easily, and there is no way to test that the exact right thing ends up back in Discord for the user.

Additional Details

N/A. I realise this is definitely a rather complex request, and likely brings a lot of potential abuse vectors with it, but I'm hoping by having it be a locked-down and isolated service account/guild, those can be drastically reduced and extra limits can be put in place etc.

[muddyfish]

Whilst we can already do limited forms of testing with two/three bots and allowlisting our main bot to listen to another bot giving commands, this does not work for weird cases such as:

• A server getting a boost
• Unusual file upload size
• Any server features, such as partnered/discoverable
• Emojis from Twitch
• Emojis that are not usable because of lost boosts
• Any flags from the target user - a bit out there but we might want to treat people from various hype squads differently
• A user/bot joining (well technically we can simulate a user joining already, but not a bot)
• Self join/leave events for the server we're testing against, including server deletion
• Emojis that have been deleted via trust and safety that are still in the guild from an API perspective but have no valid URL

I know this list contains some rather esoteric things, but they're surprising hard to test against as some require spending money, captcha solving or even just not something we can reproduce at all but will find cases of in production.

Currently we're limited to either testing in production or asking the owners of these interesting guilds if they'd be ok adding your dev bot there with zero permissions.

[casey]

This would be great. Additionally, it would be ideal if test guild channels were not subject to rate limiting. Since tests may be run in parallel, they can easily run into rate-limits. As long as test guilds have a small number of members, increasing the rate limits for messages posted to those guilds shouldn't increase load too much.

@muddyfish I wonder how you deal with this issue. I have two bots, the bot under test, and a bot that simulates user actions, both in the same channel in a test server. When I run tests individually, everything works fine, but running more than a few at once hits rate limits. Do you know if there's a way around this issue, or do you just run tests one at a time?