aboutsummaryrefslogtreecommitdiff
path: root/tests/test_deser.rs
Commit message (Collapse)AuthorAgeFilesLines
* Merge deserialization tests into oneZeyla Hellyer2018-07-311-3/+26
|
* Add `Message::member` structfieldZeyla Hellyer2018-05-211-0/+3
| | | | | Adds the `Message::member` structfield, which contains a partial amount of member data (deaf and mute status, role IDs, and joined_at).
* Add `animated` to `Emoji` and `ReactionType`Zeyla Hellyer2017-12-201-0/+5
| | | | | | | | | | Adds an animated structfield to `Emoji` and `ReactionType`'s `Custom` variant, which defaults to false if not present. A test has been added for deserializing it, taken from a REST API GET Emojis response. (cherry picked from commit 5286949f424e824784344ebb7b7af4e52fb819c3)
* Fix `Guild` deser without `system_channel_id`Zeyla Hellyer2017-12-171-0/+7
| | | | | | | Fix the deserialization of `model::guild::Guild` when `Guild::system_channel_id` is not present. Additionally, add a test case for this.
* Break up the model moduleZeyla Hellyer2017-12-161-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `model` module has historically been one giant module re-exporting all of the model types, which is somewhere around 100 types. This can be a lot to look at for a new user and somewhat overwhelming, especially with a large number of fine-grained imports from the module. The module is now neatly split up into submodules, mostly like it has been internally since the early versions of the library. The submodules are: - application - channel - error - event - gateway - guild - id - invite - misc - permissions - prelude - user - voice - webhook Each submodule contains types that are "owned" by the module. For example, the `guild` submodule contains, but not limited to, Emoji, AuditLogsEntry, Role, and Member. `channel` contains, but not limited to, Attachment, Embed, Message, and Reaction. Upgrade path: Instead of glob importing the models via `use serenity::model::*;`, instead glob import via the prelude: ```rust use serenity::model::prelude::*; ``` Instead of importing from the root model module: ```rust use serenity::model::{Guild, Message, OnlineStatus, Role, User}; ``` instead import from the submodules like so: ```rust use serenity::model::channel::Message; use serenity::model::guild::{Guild, Role}; use serenity::model::user::{OnlineStatus, User}; ```
* Fix deserialization of `Guild::application_id`Zeyla Hellyer2017-12-151-0/+6
| | | | | | | Fix the deserialization of the `Guild::application_id` structfield. Additionally, create a new ID type for it. A test has been added for this.
* Change `features` fields to be a Vec<String>Zeyla Hellyer2017-10-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When Discord adds new features, the Feature enum will not be able to serialize the new values until updated, causing the entire Guild deserialization to fail. Due to the fact that these features can be added at any time, the `features` vector on Guild and PartialGuild have been changed to be a `Vec<String>`. Upgrade path: Instead of matching on variants of Feature like so: ```rust use serenity::model::Feature; for feature in guild.features { if feature == Feature::VipRegions { // do work with this info } } ``` Instead opt to check the string name of the feature: ```rust for feature in guild.features { if feature == "VIP_REGIONS" { // do work with this info } } ```
* Fix negative nonces failing to deserializeZeyla Hellyer2017-06-101-0/+4
| | | | | | | | | | Negative message nonces caused deserialization errors, as serde would not deserialize integers into strings. To fix this, change `Message::nonce` into an `Option<Snowflake>` from an `Option<String>`. This new `Snowflake` is a wrapper around an `i64`. Use a new `I64Visitor` to deserialize i64s, u64s, and strs into the wanted i64.
* Handle message type 7 (member join)illia k2017-05-221-0/+5
| | | | | | | | | | When message type 7 is received from the gateway, transform the content if the type is 7 to a proper greeting. Additionally, when the type is 6, provide a proper content notifying that a user has pinned a message to the channel. These transformations are not done at REST-level when retrieving messages, and are instead done in `ChannelId::message` and `ChannelId::messages`.
* Fix non-custom emoji deserializationZeyla Hellyer2017-04-271-0/+2
| | | | | | | | | Deserializing a non-custom emoji would fail, as an Id would always be expected. To fix this, special-case that if a name and id are both present, to deserialize it as a Custom emoji reaction. Otherwise, use only the name and deserialize as a basic reaction.
* Fix decoding for `CurrentUser.discriminator`Zeyla Hellyer2017-04-251-0/+5
| | | | | | Due to the serde 1.0 upgrade, integers are no longer automatically deserialized from Strings. To resolve this, create a visitor that performs the operation based on the input.
* Add a test suite for event deserializationZeyla Hellyer2017-04-191-8/+134
| | | | | | | | | | | | Add a test suite for most of the events that can be easily procuced, and store them in static JSON files so the tests are ran on every build. The recent update to using serde{,_derive} for deserialization was a rough patch, as it was a large change which couldn't be fully tested at the time. By adding JSON files which are deserialized, this will produce a test suite that can be easily run on every new set of commits to prevent any backwards incompatible changes with regards to deserialization.
* Switch to using serde for deserializationZeyla Hellyer2017-04-111-0/+25
The current build system is rudimentary, incomplete, and rigid, offering little in the way of customizing decoding options. To solve this, switch to using serde-derive with custom Deserialization implementations. This allows very simple deserialization when special logic does not need to be applied, yet allows us to implement our own deserialization logic when required. The problem with the build system was that it built enums and structs from YAML files. This is not so good, because it requires creating a custom build system (which was rudimentary), creating "special struct configs" when logic needed to be ever so slightly extended (rigid), and if special logic needed to be applied, a custom deserialization method would have been needed to be made anyway (incomplete). To solve this, switch to serde-derive and implementing Deserialize ourselves where required. This reduces YAML definitions that might look like: ```yaml --- name: Group description: > A group channel, potentially including other users, separate from a [`Guild`]. [`Guild`]: struct.Guild.html fields: - name: channel_id description: The Id of the group channel. from: id type: ChannelId - name: icon description: The optional icon of the group channel. optional: true type: string - name: last_message_id description: The Id of the last message sent. optional: true type: MessageId - name: last_pin_timestamp description: Timestamp of the latest pinned message. optional: true type: string - name: name description: The name of the group channel. optional: true type: string - name: owner_id description: The Id of the group channel creator. type: UserId - name: recipients description: Group channel's members. custom: decode_users t: UserId, Arc<RwLock<User>> type: hashmap ``` to: ```rs /// A group channel - potentially including other [`User`]s - separate from a /// [`Guild`]. /// /// [`Guild`]: struct.Guild.html /// [`User`]: struct.User.html pub struct Group { /// The Id of the group channel. #[serde(rename="id")] pub channel_id: ChannelId, /// The optional icon of the group channel. pub icon: Option<String>, /// The Id of the last message sent. pub last_message_id: Option<MessageId>, /// Timestamp of the latest pinned message. pub last_pin_timestamp: Option<String>, /// The name of the group channel. pub name: Option<String>, /// The Id of the group owner. pub owner_id: UserId, /// A map of the group's recipients. #[serde(deserialize_with="deserialize_users")] pub recipients: HashMap<UserId, Arc<RwLock<User>>>, } ``` This is much simpler and does not have as much boilerplate. There should not be any backwards incompatible changes other than the old, public - yet undocumented (and hidden from documentation) - decode methods being removed. Due to the nature of this commit, field names may be incorrect, and will need to be corrected as deserialization errors are found.