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
The driver's tests so far have focused on asserting that in valid conditions, a valid behaviour is exhibited (a request is completed successfully, etc.). However, there is very few tests focusing on driver's behaviour in invalid external conditions, such as malformed message received or bad user input. What is especially dangerous is panicking in such situations, instead of e.g. returning an error from a query or printing an error! log entry.
TODO
Write more tests that accept invalid inputs and assert robust driver's behaviour, no panics in particular.
Note: These tests should be rather considered integration tests, or even e2e tests, because they check error flow through multiple driver's layers.
A probable blocker is error refactor, because only after it we will be able to truly match on QueryError; at the moment QueryError::InvalidMessage is a stringified ParseError, which itself contains a lot of stringified errors. This must be changed into matchable/downcastable error kinds.
Items to be tested
Query execution - test errors on the whole route from passing query string and values by the user up until deserializing response and providing it to the user.
TODO: add more as ideas pop up.
The text was updated successfully, but these errors were encountered:
roydahan
changed the title
epic: robustness: test that driver returns errors in invalid external conditions instead of panicking
robustness: test that driver returns errors in invalid external conditions instead of panicking
Nov 18, 2024
Problem statement
The driver's tests so far have focused on asserting that in valid conditions, a valid behaviour is exhibited (a request is completed successfully, etc.). However, there is very few tests focusing on driver's behaviour in invalid external conditions, such as malformed message received or bad user input. What is especially dangerous is panicking in such situations, instead of e.g. returning an error from a query or printing an
error!
log entry.TODO
Write more tests that accept invalid inputs and assert robust driver's behaviour, no panics in particular.
Note: These tests should be rather considered integration tests, or even e2e tests, because they check error flow through multiple driver's layers.
A probable blocker is error refactor, because only after it we will be able to truly match on
QueryError
; at the momentQueryError::InvalidMessage
is a stringifiedParseError
, which itself contains a lot of stringified errors. This must be changed into matchable/downcastable error kinds.Items to be tested
The text was updated successfully, but these errors were encountered: