Use static JSON in messages crate tests

[bobozaur]

Some corners were cut when developing the tests for the messages crate during its refactor in the sense that the JSON was being composed off of already tested structs or fields.

It would be better to use plain text JSON to ensure that any API change won't slip by the testing suite.

[SumantxD]

@bobozaur i would like to work on this issue can you help me navigate it in the project directory
Thank You.

[bobozaur]

@bobozaur i would like to work on this issue can you help me navigate it in the project directory Thank You.

Not sure what you mean. This is about most tests in msg_fields module (might be others in other modules).

The ones about msg_type deserialization are fine, but the tests that are about deserializing an actual message with fields should ideally use static messages instead of serializing certain types to avoid the situation where both the serialization and the deserialization are incorrect and thus the test passes but the result is incorrect.

[tech-bash]

I would like to try this out.

[bobozaur]

I would like to try this out.

Have at it :). Let me know if you need more information. The overall goal is simple: to replace json in tests with static JSON strings (or just static strings wrapped in the json!() macro).

As an example:

        let expected = json!({
            "credentials~attach": content.credentials_attach,
            "~thread": decorators.thread
        });

Would become something like:

        let expected = json!({
            "credentials~attach": {
                "field1": "value1",
                "field2": "value2",
            },
            "~thread": {
                "field_1": "value1",
                "field_2": "value2",
            }
        });

This way, if the inner structure of say, the Thread type changes in a breaking way, we'd be more aware and the tests aren't going to just pass, as right now we're deserializing something we just serialized.

[tech-bash]

Alright, thanks for the explanation!

[tech-bash]

In the above example you have set ~thread to two same names i.e field1 so is there any specific reason behind it or as I am thinking that, the other value could be field2 as well!

[bobozaur]

In the above example you have set ~thread to two same names i.e field1 so is there any specific reason behind it or as I am thinking that, the other value could be field2 as well!

Ah, my bad. Edited. They are supposed to be different fields, yes.