Streamline Local Development and Integration Testing Using Solo

[venilinvasilev]

Summary

Improve and standardize the local development and integration testing experience by adopting Solo as the primary local network solution. This includes adding Solo as a development dependency, providing standardized startup scripts, and ensuring all integration tests run reliably out of the box for contributors.

Problem Statement

The current local development and integration testing setup has several issues that negatively impact contributor experience:

• Outdated documentation still references running a local node for integration tests, which is deprecated.
• Solo is not integrated as a development dependency, requiring contributors to perform manual setup.
• When Solo is run in its current default configuration, it starts with only a genesis account, which is not suitable for most integration tests.
• Some integration tests (for example, freeze-related tests) fail when executed against the genesis account, which can be confusing and misleading for new contributors.
• There is no clear separation between tests that are meant to run against the genesis account and those that should use a standard, non-genesis account.

As a result, contributors may encounter failing tests despite having a seemingly correct local setup.

Proposed Solution

1. Add Solo as a Development Dependency

   • Ensure Solo is installed and managed as part of the project’s development tooling.
   • Reduce manual setup steps for contributors.

2. Provide Standardized Solo Startup Scripts

   • Create scripts for starting Solo in a configuration suitable for integration testing.
   • Scripts should be simple, consistent, and well-documented.

3. Create a Dedicated Non-Genesis Test Account

   • Automatically create and fund a standard account when Solo starts.
   • Use this account as the default payer/operator for the majority of integration tests.
   • Reserve the genesis account strictly for tests that explicitly require it.

4. Ensure All Integration Tests Pass by Default

   • With the provided Solo setup and scripts, all integration tests should run successfully without additional manual steps.
   • This should be the baseline expectation for contributors running tests locally.

5. Update Documentation

   • Replace references to local node usage with Solo-based workflows.
   • Clearly document:
     • How to start Solo for development and testing
     • Which accounts are used for which types of tests
     • Any prerequisites or assumptions

Benefits

• Improved contributor onboarding experience
• Reduced confusion caused by misleading test failures
• More reliable and reproducible integration test runs
• Clear separation of concerns between genesis and non-genesis account tests

Acceptance Criteria

• Solo is available as a development dependency
• Startup scripts for Solo are provided and documented
• A non-genesis account is created and used for most integration tests
• Genesis account usage is limited to genesis-specific tests
• All integration tests pass reliably with the documented local setup
• Documentation reflects the new workflow accurately