Website: add testing framework section

Author: dannywillems

CLAUDE.md

@@ -234,6 +234,17 @@ import ScriptName from "!!raw-loader!./path/to/script.sh";
 This ensures scripts are displayed accurately and stay in sync with the actual
 files.
 
+### Documentation Style Guidelines
+
+**Capitalization in headings and bullet points:**
+
+- Use lowercase for section headings (e.g., "Test design", "Resource
+  management")
+- Use lowercase for bullet point labels (e.g., "**Connection policies**",
+  "**State inspection**")
+- Maintain proper capitalization for proper nouns and technical terms
+- Apply this style consistently across all documentation files
+
 ### Documentation Script Testing
 
 When modifying developer setup scripts in `website/docs/developers/scripts/`,

website/docs/developers/getting-started.mdx

@@ -225,7 +225,7 @@ make postgres-setup
 make run-archive
 ```
 
-### Development Server
+### Building documentation
 
 For web development with the frontend:
 
@@ -261,28 +261,37 @@ npm install
 npm start
 ```
 
-### Testing Framework
+### Testing
 
-The Mina Rust Node includes a comprehensive testing framework:
+The Mina Rust Node includes a comprehensive testing framework with unit tests,
+integration tests, and scenario-based testing. For detailed information on
+running specific types of tests, see the
+[Testing Framework](testing/testing-framework) documentation.
+
+Quick test commands:
 
 ```bash
-# Build testing binary
-make build-testing
+# Run basic unit tests
+make test
 
-# Run specific test scenarios
-./target/release/mina-node-testing --help
+# Verify your setup works
+make test-p2p
 ```
 
 ## Next Steps
 
 1. **Explore the Codebase**: Start with
    [Architecture Documentation](./architecture.md)
-2. **Run Tests**: Ensure your setup works by running `make test`
-3. **Join the Community**: Connect with other developers on
+2. **Learn the Testing Framework**: Familiarize yourself with our comprehensive
+   [Testing Framework](testing/testing-framework) including unit tests, scenario
+   tests, and debugging tools
+3. **Run Tests**: Ensure your setup works by running tests as described in the
+   testing documentation
+4. **Join the Community**: Connect with other developers on
    [Discord](https://discord.com/channels/484437221055922177/1290662938734231552)
    and participate in discussions on the
    [Mina Protocol Forums](https://forums.minaprotocol.com/)
-4. **Read CLAUDE.md**: Check the project-specific development guide in the root
+5. **Read CLAUDE.md**: Check the project-specific development guide in the root
    directory
 
 ## Getting Help

website/docs/developers/testing/ledger-tests.md

@@ -0,0 +1,160 @@
+---
+sidebar_position: 3
+title: Ledger Tests
+description: Comprehensive ledger functionality testing
+slug: /developers/testing/ledger-tests
+---
+
+# Ledger Tests
+
+## Overview
+
+Comprehensive ledger functionality testing covers transaction processing, state
+management, and ledger operations. These tests require nightly Rust due to
+advanced features and dependencies.
+
+## Running Ledger Tests
+
+### Basic Ledger Testing
+
+```bash
+# Build ledger tests
+make build-ledger
+
+# Run ledger tests
+make test-ledger
+
+# Run with cargo-nextest
+make nextest-ledger
+```
+
+**Note**: Ledger tests require nightly Rust toolchain.
+
+## VRF Tests
+
+```bash
+# Run VRF tests
+make test-vrf
+
+# Run with cargo-nextest
+make nextest-vrf
+```
+
+**Note**: VRF tests also require nightly Rust toolchain.
+
+## Block Replayer Tool
+
+### Purpose
+
+The block replayer validates transaction and ledger logic by replaying
+historical blockchain data:
+
+- **Transaction Validation**: Verify transaction processing correctness
+- **Ledger State**: Ensure ledger state transitions are accurate
+- **Protocol Compliance**: Check adherence to protocol rules
+- **Performance Analysis**: Measure processing speeds and resource usage
+
+### Usage
+
+```bash
+# Replay blocks from chain data
+./target/release/mina replay --blocks-file chain.json
+
+# Validate specific block range
+./target/release/mina replay --start-block 1000 --end-block 2000
+```
+
+### Future development
+
+Continued development of the block replayer is recommended for:
+
+- **Enhanced validation**: More comprehensive transaction validation
+- **Performance testing**: Benchmark ledger operation performance
+- **Protocol evolution**: Test new protocol features against historical data
+- **Regression testing**: Ensure changes don't break existing functionality
+
+## Ledger testing components
+
+### Transaction processing
+
+Tests cover:
+
+- **User commands**: Payment and delegation transactions
+- **Fee transfers**: Block producer rewards and fees
+- **Coinbase**: Block reward distribution
+- **Account creation**: New account initialization
+
+### State management
+
+Validation includes:
+
+- **Account updates**: Balance and nonce changes
+- **Merkle tree operations**: Ledger tree consistency
+- **State transitions**: Valid state progression
+- **Rollback handling**: Proper state restoration
+
+### Scan state testing
+
+The scan state manages pending transactions:
+
+- **Transaction queuing**: Proper ordering and batching
+- **SNARK work integration**: Proof generation coordination
+- **Staged ledger**: Intermediate state management
+- **Fork resolution**: Handling competing chains
+
+## Performance Considerations
+
+### Resource management
+
+1. **Memory usage**: Ledger tests can be memory intensive
+2. **Disk I/O**: State persistence operations
+3. **CPU usage**: Cryptographic operations and proof verification
+4. **Test duration**: Comprehensive tests may take significant time
+
+### Optimization strategies
+
+1. **Parallel execution**: Use cargo-nextest for faster test runs
+2. **Test filtering**: Run specific test subsets during development
+3. **Mock services**: Use lightweight mocks where appropriate
+4. **Resource cleanup**: Ensure proper cleanup after tests
+
+## Best practices
+
+### Test design
+
+1. **Isolation**: Use fresh ledger state for each test
+2. **Deterministic**: Tests should produce consistent results
+3. **Coverage**: Test both success and failure scenarios
+4. **Edge cases**: Include boundary conditions and error cases
+
+### Debugging ledger tests
+
+1. **State inspection**: Examine ledger state at test failure points
+2. **Transaction tracing**: Track transaction processing steps
+3. **Merkle tree validation**: Verify tree consistency
+4. **Account state**: Check individual account changes
+
+## Integration with other components
+
+### Connection to P2P tests
+
+Ledger tests integrate with P2P testing for:
+
+- **Transaction propagation**: Ensuring transactions spread correctly
+- **Block validation**: Verifying received blocks
+- **Consensus integration**: Coordinating with consensus mechanisms
+
+### Scenario test integration
+
+Ledger functionality is tested within broader scenarios:
+
+- **Multi-node synchronization**: Consistent ledger state across nodes
+- **Fork resolution**: Proper handling of competing ledgers
+- **Performance testing**: Ledger operations under load
+
+## Related Documentation
+
+- [Testing Framework Overview](testing-framework): Main testing documentation
+- [Unit Tests](unit-tests): Basic component testing
+- [Scenario Tests](scenario-tests): Integration testing scenarios
+- [Architecture](../architecture): Overall system architecture including ledger