Conversation
Summary of ChangesHello @bhandras, 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 introduces a robust and isolated integration test environment through a new Highlights
Using Gemini Code AssistThe 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
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 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
|
Pull Request Review: Integration Test HarnessSummaryThis PR adds a comprehensive integration test harness for spinning up bitcoind, LND, and tapd instances in Docker for end-to-end testing. The implementation is well-structured and follows the project's coding standards. I've reviewed the code for quality, security, performance, and test coverage. Positive HighlightsStrong Code Quality
Good Architectural Decisions
Issues & Recommendations1. Build Tag Consistency
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive test harness for integration testing, which is a great addition. The harness sets up bitcoind, lnd, and other services in Docker, providing a realistic testing environment.
My review focuses on the new harness implementation. I've found a couple of areas for improvement:
- There's a potential bug in how payments are sent within the channel setup logic, where a failed payment would be retried.
- The
tapdcontainer is running as root, which is inconsistent withlndand not a security best practice.
I've provided specific comments and suggestions for these points. Overall, this is a solid foundation for integration testing.
PR Review: Harness Infrastructure Test EnvironmentI've reviewed this PR which adds a comprehensive Docker-based test harness for integration testing. Here's my feedback: ✅ Strengths
🔍 Code Quality Issues1. Inconsistent error handling patterns (harness.go:98)The // bicoind is the bitcoind container.
bitcoind *dockertest.Resource2. Magic numbers without constants
3. Potential resource leak (harness.go:547-550)The if h.T != nil && h.T.Failed() {
if err := h.saveLogs(); err != nil {
h.Logf("failed to save logs: %v", err)
}
}4. User ID assumptions (tapd_harness.go:180, 253)The LND container uses User: fmt.Sprintf("%d:%d", os.Getuid(), os.Getgid()), // LND
User: "0:0", // tapd - why hardcoded?The GitHub CI fix mentions this is needed for Docker mounts, but the inconsistency needs explanation or should be unified. 5. Context usage (harness.go:1149-1152)Using 6. Missing bounds checking (harness.go:1055-1063)
var height uint32
switch v := raw.(type) {
case float64:
height = uint32(v)
case int:
height = uint32(v)
default:
require.NoError(h.T, json.Unmarshal(res, &height))
}7. Build tag changes (db/test_postgres.go, db/test_sqlite.go)The renaming from
🔒 Security Considerations
⚡ Performance Considerations
🧪 Test CoverageThe canary test (
📝 Style & Convention AdherenceFollows CLAUDE.md guidelines:
Minor style issues:
🎯 Recommendations
📊 Overall AssessmentThis is high-quality infrastructure code that will significantly improve integration testing capabilities. The design is solid, with good separation of concerns and proper resource management. The issues identified are mostly minor and don't block merging, but addressing them would further improve robustness. Recommendation: Approve with minor suggestions ✅ The foundation is excellent - great work! Once the minor issues are addressed, this will be a robust test harness. |
Pull Request Review: Basic Infrastructure Test EnvironmentThis PR introduces a comprehensive test harness infrastructure for integration testing with bitcoind, LND, and tapd running in Docker containers. StrengthsArchitecture & Design
Code Quality
Testing Infrastructure
Critical Issues1. User/Permission Mismatch (harness/tapd_harness.go:253)
2. Missing Context Cancellation (harness/harness.go:1419-1424)
3. Signal Handler Issue (harness/harness.go:445-451)
Code Quality Issues4. Inconsistent Error Handling (harness/harness.go:702-737)
5. Magic Numbers (harness/harness.go:46, 49, 52)
6. Dead Code (harness/harness.go:1899-1904)
Security & PerformanceSecurity
Performance
Testing ConcernsMissing test coverage for:
Build Tag ChangesExcellent simplification: test_db_postgres/test_db_sqlite renamed to test_postgres/test_sqlite. Changes correctly propagated to workflows, golangci, Makefile, and test files. Recommendations SummaryMust Fix
Should Fix
Nice to Have
ConclusionSolid foundation for integration testing. Well-organized, properly documented, follows Go best practices. Main concerns: container user permissions and context handling. Recommendation: Approve with minor changes. User permission issue should be addressed, but PR provides significant value. This enables comprehensive integration tests previously impossible - a major quality assurance improvement. |
Pull Request Review: Basic Infrastructure Test EnvironmentSummaryThis PR introduces a comprehensive Docker-based test harness infrastructure for integration testing. The implementation adds ~3,100 lines of well-structured code to support parallel test execution with bitcoind, LND, electrs, tapd, and optional PostgreSQL containers. ✅ Strengths1. Excellent Code Organization
2. Robust Resource Management
3. Strong Testing Support
4. Good Logging Practices
5. CI Integration
|
|
@claude review pls |
|
Claude finished @bhandras's task —— View job Code Review: Harness Infrastructure Test EnvironmentI've completed a thorough review of this PR which introduces a comprehensive Docker-based test harness for integration testing with bitcoind, LND, and tapd. Overall, this is high-quality infrastructure code with excellent documentation and design. SummaryThis PR adds ~3,400 lines of well-structured test infrastructure that enables parallel integration testing with isolated Docker environments. The implementation demonstrates solid understanding of Docker orchestration, Go testing patterns, and proper resource management. ✅ Strengths1. Excellent Architecture
2. Robust Resource Management
3. Strong Documentation
4. Good Testing Infrastructure
5. CI/Build Integration
|
| Guideline | Status | Notes |
|---|---|---|
| Function comments start with function name | ✅ | Excellent throughout |
| Explain how/why, not just what | ✅ | Comments are insightful |
| 80-character line limit | ✅ | Respected with reasonable exceptions for structured logging |
| Structured logging | Harness uses fmt.Print/fmt.Printf instead of structured logging (harness.go:352, 357-363). This is acceptable for test infrastructure and covered by linter exclusion (.golangci.yml:244). |
|
| 8-space tabs | ✅ | Properly configured |
| Error handling | See issues #2 and #3 above | |
| Small, atomic commits | ✅ | Clean commit history |
Style Observations
Good:
- Logical stanzas separated by blank lines
- Early returns and immediate error checking
- Consistent naming conventions
- Type conversions handled properly (harness.go:1099-1107)
Minor:
interface{}at line 1163 could beanyfor Go 1.18+ consistency (thoughinterface{}is fine)- Some functions are long (e.g.,
Start()at 111 lines) but acceptable for lifecycle management
🔒 Security Considerations
Test-Only Credentials
The hardcoded credentials are acceptable for regtest environments:
bitcoindRPCUser = "admin1"
bitcoindRPCPass = "123"Recommendation: Add a comment clarifying these are test-only:
// bitcoindRPCUser is the RPC username for bitcoind in regtest mode.
// WARNING: This is for testing only. Never use in production.
bitcoindRPCUser = "admin1"File Permissions
Artifact directories use 0o755 (harness.go:386, 393, 419-421), which allows group/world read. Macaroons and TLS certs may be written here.
Recommendation: Consider 0o700 for directories containing sensitive data (not blocking, but good practice).
⚡ Performance & Scalability
Strengths
- ✅ Dynamic port allocation prevents test collisions
- ✅ Concurrent container startup (bitcoind + postgres)
- ✅ Pre-mining blocks before electrs for faster indexing
- ✅ Dedicated HTTP client with connection limits (harness.go:87-94)
- ✅ Optional tapd startup to speed up tests that don't need it
Test Coverage
The test suite now includes comprehensive coverage:
- ✅ Basic startup and shutdown (TestHarnessStartup)
- ✅ Block generation (TestHarnessMining)
- ✅ Wallet funding (TestHarnessFaucet)
- ✅ Mempool operations (TestHarnessMempool)
- ✅ Esplora integration (TestHarnessEsplora)
- ✅ Bitcoin RPC client (TestHarnessBitcoindRPCClient)
- ✅ Postgres mode (TestHarnessPostgres)
This addresses the test coverage concern from previous reviews! 🎉
📋 Build & CI Changes
✅ All Good
- Build tags renamed consistently across all files
- GitHub Actions workflow updated with
sudowrapper for Docker permissions - Linter configuration properly excludes harness package from
forbidigoandtagliatelle - Composite action fixed to use correct go.sum path (
.github/actions/setup-go/action.yml:2-3)
📝 Final Recommendations
Must Fix Before Merge
- Fix typo:
bicoind→bitcoind(harness.go:119) - Handle
filepath.Abs()errors (harness.go:819, tapd_harness.go:172, 244)
Should Fix
- Log errors from
saveLogs()instead of silently ignoring (harness.go:581) - Remove or document stub functions with issue references
Nice to Have
- Add warning comments to test-only credentials
- Consider tightening artifact directory permissions to
0o700
✨ Conclusion
This is excellent infrastructure work that will significantly improve integration testing capabilities for the project. The code is well-documented, follows project conventions, and demonstrates thoughtful design decisions. The comprehensive test suite (7 test functions covering all major functionality) is a great addition.
The issues identified are minor and mostly involve error handling polish. The previous review feedback has been addressed effectively, particularly the container user consistency and test coverage concerns.
Recommendation: ✅ Approve with minor fixes
Once the typo and error handling issues are addressed, this PR is ready to merge. Great work on building a robust test harness! 🚀
Pull Request Review: harness - basic infrastructure test environmentOverviewThis PR adds comprehensive test harness infrastructure for integration testing, including Docker-based bitcoind, LND, tapd, electrs, and postgres containers. The implementation is well-structured and provides a solid foundation for integration testing. ✅ Strengths
🔍 Issues & RecommendationsCritical Issues
Moderate Issues
Minor Issues / Suggestions
🔒 Security Considerations
📊 Performance Considerations
🧪 Test Coverage
📝 Documentation
Build System Integration
Final VerdictLGTM with minor recommendations This is a high-quality PR that adds substantial value to the testing infrastructure. The code is well-written, properly documented, and follows most of the project's style guidelines. The issues identified are mostly minor and can be addressed in follow-up work. Recommended Action: Approve with suggestions for follow-up improvements. Priority Actions (Optional Follow-ups)
Great work on this comprehensive test infrastructure! 🎉 |
|
Code Review: PR #5 - Test Harness Infrastructure Summary: STRENGTHS: Architecture and Design:
Code Quality:
ISSUES AND RECOMMENDATIONS:
PERFORMANCE CONSIDERATIONS:
SECURITY CONSIDERATIONS:
TEST COVERAGE: ADHERENCE TO PROJECT GUIDELINES:
RECOMMENDATIONS SUMMARY:
CONCLUSION: Recommendation: Approve with minor revisions |
Code Review: Test Harness InfrastructureThis is an excellent contribution that provides comprehensive integration test infrastructure! The code is well-structured, thoroughly tested, and follows good practices. Below is my detailed review. Overall AssessmentStrengths:
Areas for improvement:
Detailed Feedback1. Code Style & Conventions✅ Good Practices Observed:
|
Pull Request Review: Test Harness InfrastructureSummaryThis PR introduces a comprehensive Docker-based test harness for running integration tests against Bitcoin and Lightning Network infrastructure. The implementation is well-structured with good separation of concerns and extensive test coverage (86.2%). Code Quality & Best PracticesStrengths ✅
Issues & Recommendations 🔍1. Log Level Usage (CRITICAL per CLAUDE.md)Location: Throughout harness.go The code uses
Current issues:
Recommendation: Since the harness uses custom logging, ensure error conditions are clearly differentiated. Consider adding 2. Error Handling PatternsLocation: harness.go:670-687, 692-718 These functions silently ignore errors ( // harness.go:670-687
func (h *Harness) pruneStaleHarnessNetworks() {
// Best-effort, ignore errors.
nets, err := h.pool.Client.ListNetworks()
if err != nil {
return // Silent failure
}Recommendation: At minimum, log ignored errors at debug/trace level so they're visible when troubleshooting: if err != nil {
h.Logf("[DEBUG] Failed to list networks for pruning: %v", err)
return
}3. Magic NumbersLocation: harness.go:655, 1433, 1452 // harness.go:655
for i := 0; i < 5; i++ { // Why 5?
// harness.go:1097-1100
const cushion = 1000 * time.Millisecond // Why 1000ms?Recommendation: Extract to named constants with comments explaining the rationale: const (
// maxNetworkNameRetries is the number of times to retry creating
// a unique network name on collision before giving up.
maxNetworkNameRetries = 5
// blockTimeCushion adds margin beyond block time to account for
// clock skew and processing delays in time-dependent operations.
blockTimeCushion = 1000 * time.Millisecond
)4. Line LengthLocation: Multiple locations Per CLAUDE.md, aim for 80-character line limit. Several lines exceed this:
Recommendation: Wrap long lines, especially for better readability in code reviews. 5. Potential Race ConditionLocation: harness.go:456-482 func (h *Harness) startInfrastructure() {
var wg sync.WaitGroup
if *harnessPostgres {
wg.Add(1)
go func() {
defer wg.Done()
h.Log("Starting postgres...")
h.startPostgres() // Modifies h.postgres without mutex
}()
}
h.startBitcoind() // Modifies h.bitcoind
wg.Wait()
}Analysis: While Recommendation: Add a comment explaining the safety: // Safe to run concurrently as they modify independent fields
// (h.postgres vs h.bitcoind) and don't share state.6. User Specification in Docker ContainersLocation: tapd_harness.go:184, 268 User: fmt.Sprintf("%d:%d", os.Getuid(), os.Getgid()),Issue: This uses the host user's UID/GID, which works for GitHub CI (as noted in commit message) but may fail in other environments (rootless Docker, different namespaces). Recommendation: Document this requirement more prominently, perhaps in harness.go godoc: // The harness uses the current user's UID/GID for container processes
// to avoid permission issues with bind mounts. This requires proper
// Docker configuration (user namespace mapping or sudo access).7. Unimplemented StubsLocation: harness.go:1915-1920, tapd_harness.go:503-508 func (h *Harness) NewTapClientHarness(name string) interface{} {
h.T.Fatal("NewTapClientHarness not yet implemented")
return nil
}Recommendation: Either remove these stubs or add a TODO with issue number for tracking: // TODO(issue #123): Port TapClientHarness from tap-arktree when needed.Test CoverageStrengths
Recommendations
Performance Considerations✅ Good practices:
Security ConcernsMinor Issues
Build Integration✅ CI Changes look good:
RecommendationConsider documenting the sudo requirement in development_guidelines.md for local development. Commit Quality✅ Good commit structure:
Per CLAUDE.md guidelines, these could potentially be squashed further, but the current granularity is reasonable. Minor Style Issues
Final VerdictThis is a high-quality, well-tested PR that provides essential test infrastructure. The implementation follows Go best practices and project conventions from CLAUDE.md. Required Changes Before Merge:
Recommended Improvements (can be follow-up):
Approval Status: ✅ APPROVEDGreat work on this comprehensive test harness! The 86.2% test coverage and thoughtful design make this a solid foundation for integration testing. |
Docker based tests that use volumes will break on GitHub CI due to the special userid 0:0. We fix this by running unit tests with sudo on the CI.
Pull Request Review: Test Harness InfrastructureOverall AssessmentThis is an excellent, production-ready PR that introduces comprehensive test harness infrastructure. The code quality is high, follows the project's coding conventions, and provides significant value for integration testing. I found 86.2% test coverage impressive for infrastructure code. ✅ StrengthsCode Quality
Testing Infrastructure
Documentation & Observability
🔍 Code Review FindingsCritical IssuesNone found ✅ Minor Issues & Suggestions1. Error Log Levels (harness.go)Per CLAUDE.md guidelines, only use Example of correct usage (lines 593-596): if err \!= nil {
h.Logf("failed to kill %s: %v", name, err) // Info, not error - external trigger
}2. Magic NumbersSeveral magic numbers could be constants for better maintainability: harness.go:851 - Fee parameters: "-fallbackfee=0.00001",
"-minrelaytxfee=0.00000500",Suggestion: Define constants like: const (
fallbackFeeBTC = 0.00001 // ~1 sat/vB
minRelayFeeBTC = 0.00000500 // 0.5 sat/vB for test policy
)3. Resource Cleanup Edge Case (harness.go:658-660)The artifact cleanup has a minor logic issue: if h.T \!= nil && \!h.T.Failed() && \!h.opts.AlwaysKeepArtifacts {
_ = os.RemoveAll(h.artifactsDir)
}Issue: Recommendation: Either:
4. Hardcoded Docker Images (harness.go:280-282)Image versions are hardcoded in defaults: BitcoindImage: "lightninglabs/bitcoin-core:29",
LNDImage: "lightninglabs/lnd:v0.19.3-beta",
TapdImage: "lightninglabs/taproot-assets:v0.7.0-rc1",Not a blocker, but consider:
5. Context Usage (harness.go:1247-1250)Several functions create background contexts instead of accepting them: ctxt, cancel := context.WithTimeout(context.Background(), defaultTimeout)Suggestion: Accept
This allows test cancellation and proper context propagation. 6. Test Parallelism Default (harness_test.go:23)testParallelism = flag.Int("test.parallelism", 4, ...)Consideration: Default of 4 may be aggressive for resource-constrained CI environments. Document hardware requirements or consider dynamic detection. 🔒 Security Review✅ No Security Concerns Found
🚀 Performance ConsiderationsStrengths
Observations
📋 Testing & CoverageTest Coverage: 86.2% ✅Excellent coverage for infrastructure code with 8 comprehensive tests:
Testing Observations
Suggested Additional Tests
🏗️ Build & CI ConfigurationChanges Reviewed
GitHub Actions Concern.github/workflows/main.yml:176-177: run: sudo env "PATH=$PATH" "GOPATH=$GOPATH" make ${{ matrix.unit_type }}Issue: Recommendation: Consider alternative approaches: # Option 1: Fix Docker socket permissions
- name: Fix Docker permissions
run: sudo chmod 666 /var/run/docker.sock
# Option 2: Add user to docker group
- name: Add user to docker group
run: |
sudo usermod -aG docker $USER
newgrp docker📝 Style & Convention Adherence✅ Follows CLAUDE.md Guidelines
Minor Style Notes
🎯 RecommendationsHigh Priority
Medium Priority
Low Priority
🏁 ConclusionThis PR is ready to merge with only minor suggestions for future improvements. The harness infrastructure is well-designed, thoroughly tested, and will significantly improve integration testing capabilities. Approval Recommendation: ✅ APPROVEKey Achievements:
Next Steps:
Great work on this comprehensive test infrastructure! 🎉 Review generated with analysis of harness.go (1975 lines), harness_test.go (471 lines), tapd_harness.go (509 lines), and all configuration changes. |
Fourteen new tests covering the five fixes from the Codex 5.3 deep review, all passing with -race: DurableAsk outbox safety (Fix #1): - TestDurableAskNacksOnOutboxWriteFailure Promise completion ordering (Fix #3): - TestPromiseCompletionDeferredUntilAfterAck - TestPromiseNotCompletedOnAckFailure - TestPromiseCompletionDeferredInTxPath - TestPromiseNotCompletedOnTxFailure Delivery mutex (Fix #4): - TestDeliveryConcurrentExtendAndAck - TestDeliveryConcurrentExtendAndNack Poison message handling (Fix #5): - TestDurableMailboxPoisonMessageDeadLetter - TestDurableMailboxPoisonMessageNackBeforeMax Promise registry cleanup (Fix #8): - TestDurableMailboxPromiseRegistryCleanupOnEnqueueFailure Outbox ID deduplication (Fix #2): - TestDurableMailboxSendUsesOutboxIDFromContext - TestDurableMailboxSendDuplicateOutboxIDIsIdempotent - TestDurableMailboxSendWithoutOutboxIDGeneratesFreshID - TestOutboxPublisherPropagatesOutboxID The mock delivery store is updated with ON CONFLICT DO NOTHING semantics for EnqueueMessage (matching the real SQL) and per-operation error injection fields for outbox and enqueue failures.
Fourteen new tests covering the five fixes from the Codex 5.3 deep review, all passing with -race: DurableAsk outbox safety (Fix #1): - TestDurableAskNacksOnOutboxWriteFailure Promise completion ordering (Fix #3): - TestPromiseCompletionDeferredUntilAfterAck - TestPromiseNotCompletedOnAckFailure - TestPromiseCompletionDeferredInTxPath - TestPromiseNotCompletedOnTxFailure Delivery mutex (Fix #4): - TestDeliveryConcurrentExtendAndAck - TestDeliveryConcurrentExtendAndNack Poison message handling (Fix #5): - TestDurableMailboxPoisonMessageDeadLetter - TestDurableMailboxPoisonMessageNackBeforeMax Promise registry cleanup (Fix #8): - TestDurableMailboxPromiseRegistryCleanupOnEnqueueFailure Outbox ID deduplication (Fix #2): - TestDurableMailboxSendUsesOutboxIDFromContext - TestDurableMailboxSendDuplicateOutboxIDIsIdempotent - TestDurableMailboxSendWithoutOutboxIDGeneratesFreshID - TestOutboxPublisherPropagatesOutboxID The mock delivery store is updated with ON CONFLICT DO NOTHING semantics for EnqueueMessage (matching the real SQL) and per-operation error injection fields for outbox and enqueue failures.
Fourteen new tests covering the five fixes from the Codex 5.3 deep review, all passing with -race: DurableAsk outbox safety (Fix #1): - TestDurableAskNacksOnOutboxWriteFailure Promise completion ordering (Fix #3): - TestPromiseCompletionDeferredUntilAfterAck - TestPromiseNotCompletedOnAckFailure - TestPromiseCompletionDeferredInTxPath - TestPromiseNotCompletedOnTxFailure Delivery mutex (Fix #4): - TestDeliveryConcurrentExtendAndAck - TestDeliveryConcurrentExtendAndNack Poison message handling (Fix #5): - TestDurableMailboxPoisonMessageDeadLetter - TestDurableMailboxPoisonMessageNackBeforeMax Promise registry cleanup (Fix #8): - TestDurableMailboxPromiseRegistryCleanupOnEnqueueFailure Outbox ID deduplication (Fix #2): - TestDurableMailboxSendUsesOutboxIDFromContext - TestDurableMailboxSendDuplicateOutboxIDIsIdempotent - TestDurableMailboxSendWithoutOutboxIDGeneratesFreshID - TestOutboxPublisherPropagatesOutboxID The mock delivery store is updated with ON CONFLICT DO NOTHING semantics for EnqueueMessage (matching the real SQL) and per-operation error injection fields for outbox and enqueue failures.
Fourteen new tests covering the five fixes from the Codex 5.3 deep review, all passing with -race: DurableAsk outbox safety (Fix #1): - TestDurableAskNacksOnOutboxWriteFailure Promise completion ordering (Fix #3): - TestPromiseCompletionDeferredUntilAfterAck - TestPromiseNotCompletedOnAckFailure - TestPromiseCompletionDeferredInTxPath - TestPromiseNotCompletedOnTxFailure Delivery mutex (Fix #4): - TestDeliveryConcurrentExtendAndAck - TestDeliveryConcurrentExtendAndNack Poison message handling (Fix #5): - TestDurableMailboxPoisonMessageDeadLetter - TestDurableMailboxPoisonMessageNackBeforeMax Promise registry cleanup (Fix #8): - TestDurableMailboxPromiseRegistryCleanupOnEnqueueFailure Outbox ID deduplication (Fix #2): - TestDurableMailboxSendUsesOutboxIDFromContext - TestDurableMailboxSendDuplicateOutboxIDIsIdempotent - TestDurableMailboxSendWithoutOutboxIDGeneratesFreshID - TestOutboxPublisherPropagatesOutboxID The mock delivery store is updated with ON CONFLICT DO NOTHING semantics for EnqueueMessage (matching the real SQL) and per-operation error injection fields for outbox and enqueue failures.
2 participants
This PR introduces a comprehensive test harness infrastructure that provides a programmatic
integration test environment for running end-to-end tests against real Bitcoin and Lightning Network
infrastructure.
Overview
The harness creates an isolated Docker-based test environment with:
Each test run gets its own isolated Docker network, dynamic port allocation, and dedicated artifact
directories for logs and data, enabling fully parallel test execution.
Key Features
🏗️ Infrastructure Management
⚡ Performance Optimizations
🧪 Test Helpers
📊 Test Coverage