mirror of
https://github.com/logos-blockchain/logos-blockchain-testing.git
synced 2026-01-07 07:43:09 +00:00
34 lines
1.5 KiB
Markdown
34 lines
1.5 KiB
Markdown
|
# FAQ
|
|||
|
|
|
|||
|
|
**Why block-oriented timing?**
|
|||
|
|
Slots advance at a fixed rate (NTP-synchronized, 2s by default), so reasoning
|
|||
|
|
about blocks and consensus intervals keeps assertions aligned with protocol
|
|||
|
|
behavior rather than arbitrary wall-clock durations.
|
|||
|
|
|
|||
|
|
**Can I reuse the same scenario across runners?**
|
|||
|
|
Yes. The plan stays the same; swap runners (local, compose, k8s) to target
|
|||
|
|
different environments.
|
|||
|
|
|
|||
|
|
**When should I enable chaos workloads?**
|
|||
|
|
Only when testing resilience or operational recovery; keep functional smoke
|
|||
|
|
tests deterministic.
|
|||
|
|
|
|||
|
|
**How long should runs be?**
|
|||
|
|
The framework enforces a minimum of **2× slot duration** (4 seconds with default 2s slots), but practical recommendations:
|
|||
|
|
|
|||
|
|
- **Smoke tests**: 30s minimum (~14 blocks with default 2s slots, 0.9 coefficient)
|
|||
|
|
- **Transaction workloads**: 60s+ (~27 blocks) to observe inclusion patterns
|
|||
|
|
- **DA workloads**: 90s+ (~40 blocks) to account for dispersal and sampling
|
|||
|
|
- **Chaos tests**: 120s+ (~54 blocks) to allow recovery after restarts
|
|||
|
|
|
|||
|
|
Very short runs (< 30s) risk false confidence—one or two lucky blocks don't prove liveness.
|
|||
|
|
|
|||
|
|
**Do I always need seeded wallets?**
|
|||
|
|
Only for transaction scenarios. Data-availability or pure chaos scenarios may
|
|||
|
|
not require them, but liveness checks still need validators producing blocks.
|
|||
|
|
|
|||
|
|
**What if expectations fail but workloads “look fine”?**
|
|||
|
|
Trust expectations first—they capture the intended success criteria. Use the
|
|||
|
|
observability signals and runner logs to pinpoint why the system missed the
|
|||
|
|
target.
|