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
While it's important to test that things work properly, it's also very important to make sure that when things don't work properly, the app can recover and display useful information to diagnose the problem. A simple way to test this is to introduce fault injection where we insert failure points into development that we can trigger manually. For a basic implementation, I'd like this to work by us creating a fail_point macro that uses ctor to register fail points at app startup, like we do with types in specta. We would then have a window that retrieves all these fail points, and would allow us to toggle them on and off. The macro would produce code that reads from some global state (all wrapped in cfg(debug_assertions), of course) and fails if we have enabled that point.
The text was updated successfully, but these errors were encountered:
While it's important to test that things work properly, it's also very important to make sure that when things don't work properly, the app can recover and display useful information to diagnose the problem. A simple way to test this is to introduce fault injection where we insert failure points into development that we can trigger manually.
For a basic implementation, I'd like this to work by us creating a
fail_point
macro that uses ctor to register fail points at app startup, like we do with types in specta. We would then have a window that retrieves all these fail points, and would allow us to toggle them on and off. The macro would produce code that reads from some global state (all wrapped incfg(debug_assertions)
, of course) and fails if we have enabled that point.The text was updated successfully, but these errors were encountered: