Test Framework

[HopeBaron]

Test Framework

Summary

provide a testing framework that helps the developer to ensure the correct functioning of their code.

Goals

• Ability to write test code that simulates real-world breaking changes
• Provide snapshots from a server that already exists on Discord.
• Ability to use production code in your tests

Non-Goals

• This work doesn't aim to be a complete replacement of the Discord API while testing.
• This work doesn't aim to create or change requests, responses, or entities.

Motivation

Testable API allows developers to expect bugs and security flaws, while this is true, testing with the Discord API isn't because of the rate limits which forces developers to use error-prone approaches like manual testing, or time-consuming approaches like creating another bot for this goal.

The aim of the feature is to limit these scenarios, by providing a a black-box environment that simulates real-world scenarios that also allows using the elements defined in production code.

Description

kordx.test will have a class that simulates the behavior of its parent class.

XGateway - A mocked version of Gateway XRequestHandler - A mocked version of the RequestHandler

by having classes with such behaviors, we would be able to simulate interactions with DAPI effectively.

Before testing, the user would specify snapshot entities which are entities retrieved from Discord and then acted upon offline, leaving the original entities on Discord unchanged reducing API calls and IO operations.

// TODO Add code

The content will change depending on 0.4.0's implementation.

Current limitations

REST implementations don't help to achieve this goal due to the following reasons not limited to them:

Route parameters can't be accessed

While sending a response, Discord is given the parameters of the targeted function in the request (ChannelID, WebhookID, etc...), to mock this behavior, REST must expose the routeParams variable in Request.

Unserialized payload

Working with discord requires rest calls, but when working on a local computer (de)serializing Requests or responses becomes unnecessary but the current RequestHandler forces Request as a parameter and Response as a return type.