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 number of rounds required for consensus in simulations is directly influenced by the latency modeling, which simulates
message propagation delay across the network.
Currently, many tests rely on repetitive executions with varying RNG seeds to simulate random effects. While this approach
allows for parallel testing, it still relies on deterministic seed choices.
To improve testing efficiency and separate concerns between development unit testing and fuzz testing, we should integrate
fuzz testing capabilities into our tests. This change will enable:
Faster testing cycles during development, as developers won't need to wait for all repetitions to complete and fuzzing can be delegated to CI workflow marked as required to pass per PR.
Configurable fuzz testing with adjustable lengths of time.
Adherence to Golang best practices.
This improvement should also help catch edge cases like #196 more effectively, reducing the likelihood of similar issues in
the future.
The text was updated successfully, but these errors were encountered:
developers won't need to wait for all repetitions to complete
I don't understand this. Why not? Just using a different random seed doesn't make tests any better at covering the search space. Failures often happen deep in the iterations at present. If we do fewer iterations, we just won't find the bugs.
The number of rounds required for consensus in simulations is directly influenced by the latency modeling, which simulates
message propagation delay across the network.
Currently, many tests rely on repetitive executions with varying RNG seeds to simulate random effects. While this approach
allows for parallel testing, it still relies on deterministic seed choices.
To improve testing efficiency and separate concerns between development unit testing and fuzz testing, we should integrate
fuzz testing capabilities into our tests. This change will enable:
This improvement should also help catch edge cases like #196 more effectively, reducing the likelihood of similar issues in
the future.
The text was updated successfully, but these errors were encountered: