-
Notifications
You must be signed in to change notification settings - Fork 41
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc(website): add an ADR to standardize json messages testing
- Loading branch information
Showing
1 changed file
with
52 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
--- | ||
slug: 8 | ||
title: | | ||
8. Standardize JSON Message Testing | ||
authors: | ||
- name: Mithril Team | ||
tags: [Accepted] | ||
date: 2025-01-14 | ||
--- | ||
|
||
## Status | ||
|
||
Accepted | ||
|
||
## Context | ||
|
||
- To ensure backward compatibility and correctness of JSON messages exchanged between nodes, we need a standardized approach | ||
to test the deserialization of these messages. | ||
- Golden testing is a technique where the expected output (golden data) is stored and used to verify the correctness of | ||
the system's output. This approach helps in detecting unintended changes in the output and ensures that the system | ||
behaves as expected over time. | ||
- By using golden testing for JSON message deserialization, we can ensure that any changes to the message structures are | ||
backward compatible and that the deserialization process yields the expected results. | ||
- We have been using golden testing for JSON messages in the project, but the approach used ad-hoc versions that did not | ||
correspond to any OpenAPI versions, making it difficult to track the changes and maintain backward compatibility. | ||
|
||
## Decision | ||
|
||
We will standardize the testing of JSON messages by following the steps below: | ||
|
||
When adding a new JSON message structure, the following steps should be taken: | ||
- Introduce a constant `CURRENT_JSON` string containing an exhaustive example of the JSON currently exchanged between nodes. | ||
- Implement a `golden_message_current` method that returns the representation of the `CURRENT_JSON` using the current structure. | ||
- 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`. | ||
|
||
When modifying an existing JSON message structure, if backward compatibility is maintained, the following steps should be taken: | ||
- Given `X_Y_ZZ` is the version of the OpenAPI before the change: | ||
- Create a copy of the previous version structure as it was before the backward-compatible change, suffixed with the last version of the OpenAPI before the change, e.g., `CertificateMessageUntilV0_1_32`. | ||
- Implement a `golden_message_until_open_api_X_Y_ZZ` method that returns the representation of the `CURRENT_JSON` using the previous structure. | ||
- 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`. | ||
|
||
When modifying an existing JSON message structure, if backward compatibility is not maintained, the following steps should be taken: | ||
- Modify the `CURRENT_JSON` string to reflect the new structure. | ||
- Modify the `golden_message_current` method to return the representation of the `CURRENT_JSON` using the new structure. | ||
- Remove all `golden_message_until_open_api_X_Y_ZZ` method and the corresponding structure and tests, as they are no longer relevant. | ||
|
||
## Consequences | ||
|
||
- Ensures that any changes to the JSON message structure are backward compatible. | ||
- Provides a clear and standardized approach to testing JSON message deserialization. | ||
- Helps maintain the integrity and reliability of the communication between nodes. | ||
- Requires maintaining multiple versions of message structures and corresponding tests, which may increase the maintenance overhead. |