Use Released Node as Peer During Integration Tests #271
Description
Currently, during integration tests, we spin up peers using the same codebase being tested. This is essential to fully verify node intercommunication and simulate production-like environments.
To achieve this, we create a custom class loader and manipulate ports to ensure peers can run without conflicts.
While this method provides a good level of isolation, it comes with two major drawbacks:
- Self-validation problem: We are testing the current implementation against itself. In production, the network will consist of a heterogeneous mix of node versions. Our current setup risks missing incompatibilities between the new implementation and released nodes.
- Performance issues: Spinning up multiple peers this way is very slow. The current released node is heavily optimized and can start in around 1 second.
Proposal
The integration tests will be modified to no longer create peers by spinning up a custom classloader. Instead, we will use Testcontainers to dynamically pull and run the latest released live container as the peers during test execution.
This will allow us to test the current implementation against a real, production-ready node, ensuring a much higher degree of realism and interoperability.
Activity
Cryptoloveer commentedon Sep 12, 2026
I reviewed the current Cucumber harness. Peer nodes are started with isolated class loaders, share the test MySQL instance, receive a generated signer/genesis through command-line properties, and are later queried through objects stored in
PropertyHolder. Moving them toghcr.io/attocash/nodecontainers is feasible, but a few acceptance choices affect the implementation:latest, or receive an image tag through a Gradle property?Once those are confirmed, I can keep the change focused on the test harness and preserve the existing Cucumber steps.
rotilho commentedon Sep 12, 2026
Thanks for taking a look at this and for the questions!
:livetag. By default, the integration tests should continue using the classpath nodes as they do today. In the CI pipeline, however, I’d like to run two test suites in parallel: one using the current classpath-based setup, and another using the Testcontainers node pointing to:live.:liveimage.