Update testing documentation for v1.0.2

This commit is contained in:
thakares committed 2026-06-04 20:21:39 +05:30
1 parent 1004a39667
commit f4c4beb6b5
1 file changed
+220 -280
+220 -280
View File
@@ -1,81 +1,123 @@
# ChronoSeal Testing Strategy
ChronoSeal maintains a rigorous, security-first test suite focused on cryptographic correctness, deterministic server ↔ WASM parity, mutation engine integrity, replay resistance, tampering detection, behavioral validation, and storage reliability.
ChronoSeal maintains a security-focused test suite designed to validate cryptographic correctness, deterministic server ↔ WASM parity, replay resistance, mutation engine integrity, browser fingerprint validation, behavioral trust checks, storage reliability, and protocol hardening.
As of **v1.0.1**, the project contains **95 passing tests** across the server, WASM, and shared protocol crates.
As of **v1.0.2**, the project contains **100 passing tests** across the server, WASM, shared protocol, and property-testing suites.
| Crate | Tests |
| ---------------------------- | ------ |
| `chronoseal-server` | 33 |
| ------------------------------- | ------: |
| `chronoseal-server` | 38 |
| `chronoseal-wasm` | 24 |
| `shared` (unit) | 36 |
| `shared` (property-based) | 2 |
| **Total** | **95** |
| `shared` (unit tests) | 36 |
| `shared` (property-based tests) | 2 |
| `chronoseal-replay` | 0 |
| **Total** | **100** |
---
## Test Philosophy
# Test Philosophy
ChronoSeal testing prioritizes:
ChronoSeal prioritizes testing of security invariants rather than raw coverage percentages.
- **Security invariants** over raw coverage metrics
- **Deterministic parity** between server and browser WASM runtimes
- **Negative-path testing** (tampering, replay, malformed input, edge cases)
- **Property-based and fuzz-style testing** for mutation logic and VM robustness
- **Performance regression detection**
- **Long-term protocol stability**
Primary goals:
Particular emphasis is placed on ensuring that browser-side WASM execution produces identical results to server-side validation.
* Verify deterministic server ↔ WASM behavior
* Detect protocol divergence early
* Prevent replay attacks
* Validate mutation engine correctness
* Detect malformed and adversarial input handling
* Prevent VM and protocol panics
* Maintain storage backend compatibility
* Protect browser attestation continuity guarantees
The project emphasizes negative-path testing and adversarial validation rather than only testing successful execution paths.
---
# Test Categories
## 1. Configuration & CLI
## 1. Configuration & Runtime
Configuration tests verify:
- Database backend selection
- TOML configuration parsing
- Command-line override behavior
- Default configuration values
- Runtime initialization logic
* Default configuration values
* TOML parsing
* Runtime initialization
* Database backend selection
* CLI override behavior
Supported backends include:
Covered functionality:
- `sqlite-in-memory`
- `sqlite-in-disk`
- `valkey` (redis-compatible via r2d2 connection pool)
* SQLite in-memory backend
* SQLite disk backend
* Valkey compatibility mode
* Runtime configuration validation
Example tests:
```
test_apply_run_args_overrides_db_type
```text
test_default_db_type_is_sqlite_in_memory
test_apply_run_args_overrides_db_type
test_toml_parses_db_type_kebab_case
test_db_type_report_lists_backends
test_init_db_pool_sqlite_in_memory
test_init_db_pool_sqlite_in_disk
test_init_db_pool_valkey_compat_mode
test_valkey_store_operations
```
---
## 2. Session Lifecycle & Verification
## 2. Browser Fingerprint Validation
Session tests validate:
Introduced and expanded in v1.0.2.
- Session creation
- Public key validation
- Expiration handling
- Replay attack prevention
- Mutation step enforcement
- Commitment verification
- Long-running deterministic parity
Fingerprint validation protects the attestation pipeline from malformed or unrealistic browser metadata.
Validation coverage includes:
* Aspect ratio validation
* Device pixel ratio validation
* Hardware concurrency validation
* Boundary value acceptance
* NaN rejection
* Infinity rejection
* Malformed numeric value rejection
Example tests:
```text
accepts_valid_fingerprint
accepts_boundary_values
rejects_invalid_aspect_ratios
rejects_invalid_device_pixel_ratios
rejects_invalid_hardware_concurrency
```
Validation constraints currently include:
| Field | Allowed Range |
| ------------------- | --------------------- |
| aspectRatio | finite positive value |
| devicePixelRatio | greater than zero |
| hardwareConcurrency | 1..=256 |
---
## 3. Session Lifecycle & Protocol Verification
Session tests verify:
* Session creation
* Session expiration
* Public key validation
* Replay attack resistance
* Mutation commitment verification
* Mutation step enforcement
* Deterministic long-running parity
Example tests:
```text
test_create_session_rejects_invalid_public_key_length
test_expired_session_is_rejected
test_replay_attack_is_rejected
@@ -88,46 +130,19 @@ test_deterministic_server_client_parity_across_many_heartbeats
---
## 3. Mutation Engine (Core Focus)
## 4. Heartbeat Validation
The Synthetic Gene Mutation Engine is one of the most security-critical components in ChronoSeal.
Heartbeat tests validate:
Testing focuses on:
- Deterministic server/client parity
- Mutation order execution
- Gene state integrity
- Preview → Commit → Discard lifecycle
- Randomized mutation programs
- Edge-case validation
- Performance regression detection
* Successful state advancement
* Silent rejection semantics
* Commitment validation
* Rate limiting
* Next-state mutation generation
Example tests:
```
test_server_client_parity_across_random_orders
test_generate_order_is_deterministic_for_seeded_rng
test_invalid_positions_wrap_deterministically
test_mutation_chain
test_fuzz_style_random_program_bytes_do_not_diverge
test_performance_smoke_mutation_execution
```
---
## 4. Heartbeat Handler
Heartbeat validation tests verify:
- Successful state advancement
- Silent rejection behavior
- Commitment validation
- Rate limiting
- Next-state mutation generation
Example tests:
```
```text
test_handler_success_returns_next_mutation_fields
test_handler_tampered_commitment_is_silent_failure
test_handler_rate_limit_returns_no_mutation_data
@@ -135,20 +150,21 @@ test_handler_rate_limit_returns_no_mutation_data
---
## 5. Trust & Behavioral Validation
## 5. Behavioral Trust Validation
Behavioral validation tests verify:
Trust validation focuses on lightweight behavioral signals.
- Minimum mouse activity
- Minimum movement distance
- Pause detection
- Speed thresholds
- Optional activity requirements
- Fingerprint-related validation paths
Coverage includes:
* Minimum event count
* Minimum movement distance
* Pause detection
* Maximum speed thresholds
* Activity requirement toggles
Example tests:
```
```text
test_validate_mouse_success
test_validate_mouse_insufficient_events
test_validate_mouse_insufficient_distance
@@ -161,51 +177,79 @@ test_validate_mouse_require_activity_toggle
## 6. Storage Layer
Storage tests verify:
Storage tests verify backend correctness and concurrency behavior.
- SQLite in-memory operation
- SQLite disk-backed operation and pool concurrency
- Valkey compatibility mode and r2d2 pool concurrency
- Session CRUD behavior including the `opcodes` field
- Expiration cleanup
- Runtime statistics reporting
Covered backends:
These tests ensure storage implementations remain interchangeable without affecting protocol behavior.
* SQLite in-memory
* SQLite disk
* Valkey compatibility mode
Example tests:
```
```text
test_sqlite_pool_concurrency
test_valkey_pool_concurrency
test_valkey_store_operations
```
> **Note:** The concurrent write collision path in `update_session` (the `old_last_hash`
> optimistic concurrency guard) is not yet covered by an automated test. Two goroutines
> advancing the same chain simultaneously is a security-relevant race condition.
> A dedicated test is planned for v1.1.0 (see Future Improvements).
Validation includes:
* Session persistence
* Session updates
* Concurrent access
* Statistics collection
* Backend compatibility
---
## 7. VM Core
## 7. Rate Limiting
The VM core is tested extensively across both WASM and shared crates.
Rate limiter tests verify:
Coverage includes:
- ADD, SUB, MUL, XOR, AND, OR, NOT, HASH, ROT, PUSH
Edge cases include:
- Stack underflow
- Truncated instructions
- Unknown opcodes
- Wrapping arithmetic
- Invalid instruction streams
* Request counting
* Window expiration
* Stale entry eviction
Example tests:
```text
test_rate_limiter
test_rate_limiter_eviction
```
---
## 8. VM Core
The VM implementation is tested across both WASM and shared crates.
Covered operations:
```text
ADD
SUB
MUL
XOR
AND
OR
NOT
HASH
ROT
PUSH
```
Validation includes:
* Wrapping arithmetic
* Stack underflow detection
* Invalid opcode rejection
* Truncated instruction rejection
* Instruction safety
Example tests:
```text
test_add
test_add_wrapping
test_sub
@@ -221,163 +265,86 @@ test_rejects_truncated_instruction
---
## 8. Property-Based Tests
## 9. Synthetic Gene Mutation Engine
ChronoSeal uses [`proptest`](https://github.com/proptest-rs/proptest) for property-based testing of core protocol invariants against arbitrary random input.
The mutation engine is a critical security component.
Tests live in `shared/tests/proptests.rs` and run as part of `cargo test --workspace`.
Coverage includes:
```
test_vm_execute_never_panics
test_gene_environment_roundtrip_never_panics
```
`test_vm_execute_never_panics` feeds arbitrary `Vec<u8>` byte sequences into the stack machine
and asserts that execution never panics and that the instruction pointer never exceeds the
program length. This guards against any future VM opcode handler introducing undefined
behaviour on malformed input.
`test_gene_environment_roundtrip_never_panics` feeds arbitrary bytes into
`gene::decode_environment` and asserts graceful failure rather than a panic, covering the full
space of malformed environment payloads a client could send.
---
# Server Test Coverage (`chronoseal-server`)
The server crate currently contains **33 tests** covering:
- Configuration
- Runtime initialization
- Session management
- Heartbeat validation
- Rate limiting
- Trust validation
The server tests focus heavily on protocol enforcement and security validation.
---
# WASM Test Coverage (`chronoseal-wasm`)
The WASM crate currently contains **24 tests** covering:
- VM execution
- Browser-side mutation lifecycle
- Gene initialization
- Mutation preview
- Mutation commit/discard behavior
- Deterministic parity with shared logic
* Mutation order execution
* Deterministic parity
* Randomized mutation programs
* Preview lifecycle
* Commit lifecycle
* Discard lifecycle
* Environment validation
* Gene integrity
Example tests:
```
```text
test_mutation_chain
test_generate_order_is_deterministic_for_seeded_rng
test_server_client_parity_across_random_orders
test_preview_commitment_matches_shared_engine
test_commit_applies_preview
test_discard_preview_keeps_committed_state
test_table_driven_parity_across_many_generated_orders
test_fuzz_style_random_program_bytes_do_not_diverge
```
These tests ensure browser-generated commitments remain consistent with server expectations.
---
# Shared Crate Coverage (`shared`)
## 10. Property-Based Testing
The shared crate currently contains **36 unit tests** and **2 property-based tests**, representing
the core protocol implementation used by both server and browser runtimes.
ChronoSeal uses `proptest` to validate protocol invariants under arbitrary input.
Coverage includes:
Property tests:
### Synthetic Gene Engine
```
test_new_state_with_default_size
test_new_state_rejects_invalid_sizes
test_commitment_changes_when_gene_or_environment_changes
test_encode_decode_environment_roundtrip
test_table_driven_randomized_environment_roundtrip
```
### Mutation Engine
```
test_opcode_insert
test_opcode_delete
test_opcode_mutate_point
test_opcode_apply_mutagen
test_opcode_finalize_gene_hash
test_mutation_chain
```
### Validation & Hardening
```
test_rejects_stack_underflow
test_rejects_truncated_instruction
test_rejects_unknown_opcode
test_zero_length_gene_is_rejected
```
### Deterministic Parity
```
test_server_client_parity_across_random_orders
test_generate_order_is_deterministic_for_seeded_rng
test_invalid_positions_wrap_deterministically
```
### Fuzz & Regression Testing
```
test_fuzz_style_random_program_bytes_do_not_diverge
test_performance_smoke_mutation_execution
test_vm_instruction_budget_soft_cap
```
### Property-Based Tests (`shared/tests/proptests.rs`)
```
```text
test_vm_execute_never_panics
test_gene_environment_roundtrip_never_panics
```
---
# Tooling Crates
## `chronoseal-replay`
A standalone replay and audit tool for offline verification of recorded ChronoSeal session
chains. It is a developer and forensic utility, not a library, and currently carries no
automated tests. Integration tests against captured session fixtures are planned.
## `fuzz/`
Contains libFuzzer targets for deeper coverage of the VM and gene codec. Run separately
via `cargo +nightly fuzz run <target>` — not part of the standard `cargo test` suite.
These tests continuously exercise malformed and randomized inputs to ensure graceful handling and panic resistance.
---
# Running the Test Suite
Run the full workspace:
Run all tests:
```
```bash
cargo test --workspace
```
Run individual crates:
Run server tests:
```
cargo test -p shared
cargo test -p chronoseal-wasm
```bash
cargo test -p chronoseal-server
```
Display test output:
Run fingerprint tests only:
```bash
cargo test -p chronoseal-server fingerprint
```
Run WASM tests:
```bash
cargo test -p chronoseal-wasm
```
Run shared tests:
```bash
cargo test -p shared
```
Show output:
```bash
cargo test -- --nocapture
```
@@ -385,71 +352,44 @@ cargo test -- --nocapture
# Critical Security Tests
The following tests protect ChronoSeal's core protocol guarantees and should be treated as
**release-blocking** if they fail:
The following tests are considered release-blocking:
```
test_mutation_commitment_tamper_is_rejected
```text
test_replay_attack_is_rejected
test_mutation_commitment_tamper_is_rejected
test_handler_tampered_commitment_is_silent_failure
test_server_client_parity_across_random_orders
test_deterministic_server_client_parity_across_many_heartbeats
test_fuzz_style_random_program_bytes_do_not_diverge
test_server_client_parity_across_random_orders
test_vm_execute_never_panics
test_gene_environment_roundtrip_never_panics
rejects_invalid_aspect_ratios
rejects_invalid_device_pixel_ratios
rejects_invalid_hardware_concurrency
```
These tests directly validate resistance to replay attacks, protocol divergence, mutation
tampering, commitment forgery, and VM panic on adversarial input.
---
# Contributing New Tests
When adding new functionality:
1. Prefer placing protocol logic tests in `shared/`
2. Ensure server ↔ WASM parity is validated
3. Include negative-path test cases
4. Add randomized or property-based testing where appropriate
5. Update this document when introducing major new categories
---
# Future Improvements
- **Concurrent chain write collision test** — verify that two simultaneous heartbeats for the
same session are handled correctly by the `old_last_hash` optimistic concurrency guard in
`update_session` (security-critical, planned for v1.1.0)
- **Browser-driven end-to-end integration tests** — full Playwright or wasm-bindgen-test
harness exercising the complete init → heartbeat loop in a real browser environment
- **Valkey failover testing** — verify graceful degradation and reconnection under r2d2 pool
exhaustion and server-side connection drops
- **Automated benchmark execution in CI** — enforce performance regression thresholds for
mutation engine and hash chain operations
- **Expanded mutation-engine fuzzing** — additional libFuzzer targets for `vm_extensions`
opcodes introduced in v0.7.0
- **CI-enforced performance regression thresholds** — gate releases on measured latency bounds
These tests directly protect protocol integrity, replay resistance, mutation validation, deterministic execution, and fingerprint hardening.
---
# Conclusion
ChronoSeal's testing strategy is centered on preserving deterministic behavior, cryptographic
correctness, and protocol integrity.
ChronoSeal's testing strategy focuses on preserving deterministic behavior, protocol integrity, cryptographic correctness, browser ↔ server parity, and resistance to malformed or adversarial input.
The current suite of **95 tests** provides broad coverage across:
The current suite of **100 passing tests** provides comprehensive coverage across:
- Session security
- Heartbeat validation
- Mutation engine correctness
- Deterministic server/WASM parity
- Trust and behavioral validation
- Storage abstraction
- Replay resistance
- Protocol hardening
- Property-based VM and gene codec robustness
* Configuration
* Runtime initialization
* Browser fingerprint validation
* Session lifecycle management
* Heartbeat verification
* Mutation engine execution
* VM safety
* Behavioral validation
* Storage backends
* Replay resistance
* Property-based protocol hardening
Maintaining and expanding this test suite remains a core project priority as ChronoSeal evolves.
Maintaining and expanding this test suite remains a core project priority.
**Last Updated:** June 2026 (v1.0.2)
**Last Updated:** May 2026 (v1.0.1)