You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- To ensure backward compatibility and correctness of JSON messages exchanged between nodes, we need a standardized approach
18
+
to test the deserialization of these messages.
19
+
- Golden testing is a technique where the expected output (golden data) is stored and used to verify the correctness of
20
+
the system's output. This approach helps in detecting unintended changes in the output and ensures that the system
21
+
behaves as expected over time.
22
+
- By using golden testing for JSON message deserialization, we can ensure that any changes to the message structures are
23
+
backward compatible and that the deserialization process yields the expected results.
24
+
- We have been using golden testing for JSON messages in the project, but the approach used ad-hoc versions that did not
25
+
correspond to any OpenAPI versions, making it difficult to track the changes and maintain backward compatibility.
26
+
27
+
## Decision
28
+
29
+
We will standardize the testing of JSON messages by following the steps below:
30
+
31
+
When adding a new JSON message structure, the following steps should be taken:
32
+
33
+
- Introduce a constant `CURRENT_JSON` string containing an exhaustive example of the JSON currently exchanged between nodes.
34
+
- Implement a `golden_message_current` method that returns the representation of the `CURRENT_JSON` using the current structure.
35
+
- Implement a `test_current_json_deserialized_into_current_message` test that checks that deserializing the `CURRENT_JSON` into the current structure yields the output stored in `golden_message_current`.
36
+
37
+
When modifying an existing JSON message structure, if backward compatibility is maintained, the following steps should be taken:
38
+
39
+
- Given `X_Y_ZZ` is the version of the OpenAPI before the change:
40
+
- Create a copy of the previous version structure as it was before the backward-compatible change, suffixed with `UntilVX_Y_ZZ`, e.g., `CertificateMessageUntilV0_1_32`.
41
+
- Create a copy the `golden_message_current` method named `golden_message_until_open_api_X_Y_ZZ`, and update its return type to the version structure suffixed with `UntilVX_Y_ZZ`.
42
+
- Implement a `test_current_json_deserialized_into_message_supported_until_open_api_X_Y_ZZ` test that checks that deserializing the `CURRENT_JSON` into the previous structure yields the output stored in `golden_message_until_open_api_X_Y_ZZ`.
43
+
- Modify the `CURRENT_JSON` string to reflect the new structure.
44
+
- Modify the `golden_message_current` method to return the representation of the `CURRENT_JSON` using the new structure.
45
+
46
+
When modifying an existing JSON message structure, if backward compatibility is not maintained, the following steps should be taken:
47
+
48
+
- Modify the `CURRENT_JSON` string to reflect the new structure.
49
+
- Modify the `golden_message_current` method to return the representation of the `CURRENT_JSON` using the new structure.
50
+
- Remove all `golden_message_until_open_api_X_Y_ZZ` method and the corresponding structure and tests, as they are no longer relevant.
51
+
52
+
## Consequences
53
+
54
+
- Ensures that any changes to the JSON message structure are backward compatible.
55
+
- Provides a clear and standardized approach to testing JSON message deserialization.
56
+
- Helps maintain the integrity and reliability of the communication between nodes.
57
+
- Requires maintaining multiple versions of message structures and corresponding tests, which may increase the maintenance overhead.
0 commit comments