Skip to content

Conversation

@chatton
Copy link
Contributor

@chatton chatton commented Jan 27, 2026

Overview

This PR extracts out some common helper functionality that will be able to be used in some follow up compatibility tests.

Extract common EVM test infrastructure to reusable helpers:
- RethSetup struct and SetupRethNode() for Reth node setup
- SetupCelestiaAndDABridge() returns DA address
- WaitForEVMHealthy() for evmsingle health checks
- SetupEthClient() creates and verifies eth client
- WaitForTxIncluded() waits for transaction inclusion

Refactor EVMSingleUpgradeTestSuite to use the shared helpers,
reducing code duplication and enabling future test reuse.
@github-actions
Copy link
Contributor

The latest Buf updates on your PR. Results from workflow CI / buf-check (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed⏩ skipped✅ passed✅ passedJan 27, 2026, 1:08 PM

@claude
Copy link
Contributor

claude bot commented Jan 27, 2026

Claude finished @chatton's task in 2m 12s —— View job


Code Review Complete ✅

This is an excellent refactoring that successfully extracts common Docker E2E test infrastructure into reusable helpers. The changes reduce code duplication, improve maintainability, and set up a solid foundation for future tests.


🎯 Overall Assessment

Strengths:

  • Net -3 lines of code while adding reusable functionality
  • Clean extraction of 5 well-scoped helper functions
  • Proper use of Go struct composition (embedding DockerTestSuite)
  • Follows existing codebase patterns and test structure

Impact: This refactoring will significantly benefit future test development by providing ready-to-use infrastructure components.


📋 Detailed Review

1. Code Quality & Architecture ✅

Well-Structured Helpers:
All extracted helpers have clear, single responsibilities:

  • SetupRethNode() - Complete Reth node lifecycle with connectivity checks
  • SetupCelestiaAndDABridge() - Full Celestia + DA bridge setup, returns DA address
  • WaitForEVMHealthy() - Health check polling with appropriate timeout
  • SetupEthClient() - Client creation with chain ID verification
  • WaitForTxIncluded() - Transaction inclusion polling

Good Design Choices:

  • RethSetup struct (docker_test.go:254-262) clearly documents internal vs external URLs in comments - excellent for Docker networking context
  • Embedding DockerTestSuite in EVMSingleUpgradeTestSuite (upgrade_test.go:32-33) enables clean helper reuse without duplication
  • All helpers use the testify suite pattern consistently

2. Error Handling & Resilience ✅

Timeout Handling:

  • SetupRethNode() (docker_test.go:275-289): 60s timeout with 2s interval - appropriate for container startup
  • WaitForEVMHealthy() (docker_test.go:330-338): 120s timeout - generous for EVM node initialization (good choice given complexity)
  • WaitForTxIncluded() (docker_test.go:355-361): 30s timeout - reasonable for block production

Network Reliability:

  • Proper TCP connection verification in SetupRethNode() (docker_test.go:280-284) before returning
  • HTTP health checks with context and proper defer resp.Body.Close() (docker_test.go:336)

Considerations:

  • All helpers use s.Require() assertions which panic on failure - this is correct for test setup code where continuation would be meaningless

3. Resource Management & Cleanup 🔍

Observation - Resource Lifecycle:
The helpers create Docker resources (containers, networks) but don't explicitly handle cleanup. Looking at the suite structure, I assume cleanup is handled by:

  1. Suite teardown methods (not visible in this PR)
  2. The tastora framework itself
  3. Test runner cleanup

Recommendation: Consider documenting the cleanup strategy, especially for future test authors. For example, in docker_test.go:

// DockerTestSuite provides shared test infrastructure for Docker E2E tests.
// Resources created by helper methods are automatically cleaned up by the
// suite teardown or the tastora framework.
type DockerTestSuite struct {
    // ...
}

4. Testing Patterns ✅

Excellent Test Organization:
The refactored TestEVMSingleUpgrade() (upgrade_test.go:52-99) demonstrates clean test structure:

  • Setup phase clearly separated into sub-runs
  • Pre-upgrade transaction batch
  • Upgrade execution
  • Post-upgrade verification (transaction persistence, new transactions, balances)

Helper Composition:
The test now reads as a series of meaningful operations rather than implementation details:

s.daAddress = s.SetupCelestiaAndDABridge(ctx)  // Clear intent
s.reth = s.SetupRethNode(ctx)                   // Clean abstraction

5. Performance & Concurrency ✅

Efficient Polling:

  • All Eventually() calls use reasonable intervals (1-2 seconds)
  • No busy-waiting or excessive CPU usage
  • Context-aware HTTP requests (docker_test.go:331)

No Concurrency Issues:

  • Test helpers are designed for sequential execution (appropriate for Docker E2E setup)
  • No shared mutable state between tests
  • Suite fields properly isolated per test run

6. Documentation & Developer Experience ✅

Good Documentation:

  • RethSetup struct has clear field comments distinguishing internal/external URLs (docker_test.go:257-259)
  • getEvNodeImage() function has comprehensive comment explaining env vars (docker_test.go:237-239)
  • Test sub-run names are descriptive (upgrade_test.go:57-98)

Minor Enhancement Opportunity:
Consider adding godoc comments to exported helper methods for discoverability:

// SetupRethNode creates and starts a Reth node, waits for it to be ready,
// and returns connection details. Fails the test if the node doesn't start
// within 60 seconds.
func (s *DockerTestSuite) SetupRethNode(ctx context.Context) RethSetup {

7. Security Considerations ✅

No Security Issues Detected:

  • Test private key is clearly marked as test-only (upgrade_test.go:26)
  • No credentials logged or exposed
  • JWT secrets properly handled through the reth node API
  • Auth tokens retrieved securely through the bridge node API (docker_test.go:221)

🔧 Specific Code Observations

docker_test.go:286-287 - URL Construction

setup.EthURL = fmt.Sprintf("http://%s:%s", networkInfo.Internal.Hostname, networkInfo.Internal.Ports.RPC)
setup.EthURLExternal = fmt.Sprintf("http://0.0.0.0:%s", networkInfo.External.Ports.RPC)

✅ Correctly differentiates between internal (container-to-container) and external (host-to-container) URLs

docker_test.go:301 - Method Return Value

func (s *DockerTestSuite) SetupCelestiaAndDABridge(ctx context.Context) string {

✅ Returns DA address directly - simpler than returning the bridge node object

upgrade_test.go:141-148 - Transaction Submission Loop

for i := range txCount {
    tx := evm.GetRandomTransaction(s.T(), testPrivateKey, testToAddress, evmChainID, testGasLimit, &s.txNonce)
    err := s.ethClient.SendTransaction(ctx, tx)
    s.Require().NoError(err)
    txHashes = append(txHashes, tx.Hash())
    s.T().Logf("Submitted pre-upgrade tx %d: %s", i, tx.Hash().Hex())
    s.WaitForTxIncluded(ctx, s.ethClient, tx.Hash())
}

✅ Good use of range txCount (Go 1.22+ syntax). Properly waits for each tx sequentially to maintain nonce ordering.


🎯 Recommendations for Follow-up

Priority: Low

  1. Add godoc comments to public helper methods for better IDE integration
  2. Document cleanup strategy in DockerTestSuite struct comment
  3. Consider extracting constants like timeout durations if they're reused across tests:
    const (
        rethStartupTimeout = 60 * time.Second
        evmHealthTimeout   = 120 * time.Second
        txInclusionTimeout = 30 * time.Second
    )

Optional Enhancements

  1. Return structured error context from Eventually() failures - though current messages are already good
  2. Add test helpers for common patterns like "setup full environment" if multiple tests need identical setup

✅ CI/Testing Validation

Since this PR is a refactoring, please verify:

  • All Docker E2E tests pass (including TestBasicDockerE2E which uses some of the same helpers)
  • No regressions in test timing or flakiness
  • Build tags are correctly applied (//go:build docker_e2e && evm)

🎉 Conclusion

This is a high-quality refactoring that successfully achieves its goals:

  • ✅ Reduces code duplication (138 lines removed, 117 added - net improvement)
  • ✅ Creates reusable, well-scoped helper functions
  • ✅ Improves readability of EVMSingleUpgradeTestSuite
  • ✅ Sets up infrastructure for future compatibility tests
  • ✅ Maintains proper error handling and resource management
  • ✅ Follows Go and testify best practices

Recommendation: Approve and merge after CI passes. The minor enhancements suggested above are optional and could be addressed in follow-up PRs if desired.


@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @chatton, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on refactoring the end-to-end (e2e) tests by extracting common infrastructure setup and utility functions into reusable helpers within the DockerTestSuite. This change aims to reduce code duplication, improve maintainability, and facilitate the creation of new tests by providing a set of pre-built tools for setting up and interacting with the testing environment.

Highlights

  • Refactoring: Extracts common EVM test infrastructure into reusable helper functions within the DockerTestSuite.
  • New Helpers: Introduces RethSetup struct and SetupRethNode() for Reth node setup, SetupCelestiaAndDABridge() to return the DA address, WaitForEVMHealthy() for EVM health checks, SetupEthClient() to create and verify an Ethereum client, and WaitForTxIncluded() to wait for transaction inclusion.
  • Code Reduction: Refactors EVMSingleUpgradeTestSuite to utilize the shared helpers, reducing code duplication and promoting reuse in future tests.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request effectively refactors common test helper functionality into the DockerTestSuite, which significantly cleans up the EVMSingleUpgradeTestSuite and improves code reuse. The extraction of setup logic for Reth, Celestia, and DA bridges into shared helpers is well-executed. I have one minor suggestion to improve error handling in one of the new helper functions.

Comment on lines +331 to +337
req, _ := http.NewRequestWithContext(ctx, http.MethodGet, healthURL, nil)
resp, err := http.DefaultClient.Do(req)
if err != nil {
return false
}
defer resp.Body.Close()
return resp.StatusCode == http.StatusOK
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

It's good practice to handle all errors, even those that seem unlikely. The error from http.NewRequestWithContext is currently ignored. Checking it would make the code more robust. The suggested change also renames an error variable to avoid a redeclaration conflict that would arise from handling this new error.

		req, reqErr := http.NewRequestWithContext(ctx, http.MethodGet, healthURL, nil)
		if reqErr != nil {
			return false
		}
		resp, err := http.DefaultClient.Do(req)
		if err != nil {
			return false
		}
		defer resp.Body.Close()
		return resp.StatusCode == http.StatusOK

@codecov
Copy link

codecov bot commented Jan 27, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.98%. Comparing base (2325ace) to head (2010c44).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #3017   +/-   ##
=======================================
  Coverage   57.98%   57.98%           
=======================================
  Files         110      110           
  Lines       10522    10522           
=======================================
  Hits         6101     6101           
  Misses       3770     3770           
  Partials      651      651           
Flag Coverage Δ
combined 57.98% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants