Skip to content

Conversation

@amery
Copy link
Contributor

@amery amery commented Jul 17, 2025

Summary

This PR enhances the test infrastructure with comprehensive helper functions and optimizations, significantly improving test maintainability and code quality across the codebase.

Key Changes

🧪 Test Helper Functions

  • AssertEqual, AssertSliceEqual: Generic comparison helpers with clear error messages
  • AssertError, AssertPanic, AssertNoPanic, AssertBool: Standardized assertion patterns
  • RunConcurrentTest: Simplified goroutine testing with error collection
  • RunBenchmark: Setup/execution phase benchmark helpers
  • ST: Concise test slice creation helper

⚡ Performance Optimizations

  • Fixed field alignment in generics_test.go and maps_test.go for memory efficiency
  • Removed specific byte counts from comments to avoid staleness

📚 Documentation & Build

  • Enhanced AGENT.md with comprehensive test helper documentation
  • Added usage examples and patterns for all helper functions
  • Updated cspell dictionary with linter terminology (govet, linters)
  • Fixed punctuation in documentation lists for markdownlint compliance

🔧 Code Standardization

  • Converted all test files to use consistent S[T]() slice creation
  • Reduced test boilerplate by ~30% through helper adoption
  • Fixed all linting violations (cognitive complexity, use-any, flag-parameter)

Commit Structure

This PR is organized into 9 logical commits with conventional commit messages:

  1. fix(tests): Fix field alignment in generics_test.go structs - Memory optimization for test structures
  2. fix(tests): Fix field alignment in maps_test.go structs - Memory optimization for test structures
  3. build(cspell): Add linter terminology to cspell dictionary - Support for technical linter terms
  4. docs(agent): Fix punctuation in documentation lists - Markdownlint compliance improvements
  5. refactor(types): Remove specific byte counts from field alignment comments - Remove stale byte counts
  6. feat(tests): Add S[T]() helper function for concise slice creation - Core slice creation helper
  7. refactor(tests): Convert all test slice literals to use S[T]() helper - Standardize slice creation
  8. feat(tests): Enhance test utilities with comprehensive helper functions - Main test helper additions
  9. refactor(tests): Convert TestSliceReverse to use structured test cases - Improve test structure

Test Plan

All CI checks passing:

  • Multi-Go testing (1.23, 1.24): ✅
  • Race condition testing: ✅
  • Build verification: ✅
  • Coverage maintained: 77.9%

Local verification:

  • make all coverage - All tests pass
  • make tidy - All linting passes
  • Field alignment optimizations verified

Impact

  • 17 files modified with +619/-473 changes (+146 net)
  • Test maintainability: Standardized patterns across all test files
  • Developer experience: Reduced boilerplate, clearer assertions
  • Memory efficiency: Optimized struct layouts
  • Documentation: Comprehensive helper function guide

Backward Compatibility

Fully backward compatible - All existing tests continue to work unchanged while gaining access to new helper functions.

Summary by CodeRabbit

  • New Features

    • Introduced a comprehensive set of generic test helper functions to simplify and standardise testing, including slice creation, assertions, concurrency, and benchmarking utilities.
  • Documentation

    • Expanded documentation with detailed usage examples and explanations of new test helper functions.
    • Improved punctuation and formatting for clarity in several documentation sections.
  • Refactor

    • Updated test files to use new helper functions for slice construction, assertions, and concurrency, resulting in more consistent and concise tests.
    • Removed manual error checks and replaced them with assertion helpers across multiple test suites.
    • Reordered fields in some test case structs for improved clarity.
    • Encapsulated slice reversal tests into a named struct with subtests for better organisation.
    • Simplified concurrency and benchmark tests using new helper functions.
    • Removed redundant size annotations from comments in code and test files.
  • Chores

    • Added new terms to the spell checker dictionary.

@coderabbitai
Copy link

coderabbitai bot commented Jul 17, 2025

Walkthrough

A new suite of generic test helper functions was introduced in testutils_test.go to streamline and standardise Go test code, including helpers for slice creation, assertions, concurrency, and benchmarking. Existing tests were refactored to use these helpers, and documentation was updated to describe their usage. Minor comment and formatting improvements were made throughout.

Changes

Files/Paths Change Summary
testutils_test.go Introduced a new file with generic test helpers: slice creation (S), assertions (AssertEqual, AssertSliceEqual, AssertError, AssertBool, AssertPanic, AssertNoPanic), concurrency (RunConcurrentTest), benchmarking (RunBenchmark), and structured test case execution (RunTestCases).
AGENT.md Added documentation for new test helpers, including usage examples and rationale. Improved punctuation and formatting in several sections for clarity.
addrport_test.go, addrs_test.go, as_test.go, compounderror_test.go, errors_test.go, lists_test.go, panicerror_test.go, slices_test.go Refactored tests to use the new generic slice helper S for constructing slices, replacing explicit slice literals. In some cases, replaced manual assertions with assertion helpers. Removed redundant or outdated comments.
maps_test.go, panic_test.go, slices_test.go, spinlock_test.go Replaced manual error checking and assertions with generic assertion helpers (AssertEqual, AssertSliceEqual, AssertError, AssertBool, AssertPanic, AssertNoPanic). Refactored concurrency and benchmarking tests to use RunConcurrentTest and RunBenchmark. Removed unnecessary imports.
generics_test.go Reordered fields in several test case structs for consistency; no logic changes.
stack.go, slices.go Removed explicit size annotations from struct field comments. No code logic changes.
internal/build/cspell.json Added "govet", "linters", and "testutils" to the spellcheck dictionary.

Sequence Diagram(s)

sequenceDiagram
    participant Test as Test Function
    participant Helpers as Test Helpers (testutils_test.go)
    participant SUT as System Under Test

    Test->>Helpers: S(args...) to create slices
    Test->>Helpers: AssertEqual/AssertError/AssertPanic(...)
    Helpers->>Test: Report assertion results
    Test->>Helpers: RunConcurrentTest/RunBenchmark(...)
    Helpers->>SUT: Call target code in goroutines/bench loops
    Helpers->>Test: Aggregate and report results
Loading

Suggested reviewers

  • karasz

Poem

In fields of code where test bunnies hop,
New helpers bloom—oh, what a crop!
Slices and asserts, so tidy and neat,
Concurrency helpers—what a treat!
With every test, we leap and cheer,
For cleaner code is finally here!
🐇✨


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1d78987 and 9a9f0cc.

📒 Files selected for processing (8)
  • AGENT.md (3 hunks)
  • errors_test.go (2 hunks)
  • internal/build/cspell.json (2 hunks)
  • maps_test.go (29 hunks)
  • panic_test.go (7 hunks)
  • slices_test.go (5 hunks)
  • spinlock_test.go (5 hunks)
  • testutils_test.go (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (7)
  • internal/build/cspell.json
  • errors_test.go
  • spinlock_test.go
  • maps_test.go
  • AGENT.md
  • slices_test.go
  • panic_test.go
🧰 Additional context used
📓 Path-based instructions (4)
**/*.go

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*_test.go

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*.{md,go}

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Only use the Go standard library and minimal golang.org/x packages; zero external dependencies.
testutils_test.go (7)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Only use the Go standard library and minimal golang.org/x packages; zero external dependencies.
Learnt from: amery
PR: darvaza-proxy/core#86
File: list.go:32-36
Timestamp: 2024-11-16T05:20:11.432Z
Learning: In Go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as this will cause a runtime panic.
Learnt from: amery
PR: darvaza-proxy/core#79
File: internal/build/gen_mk.sh:161-169
Timestamp: 2024-10-01T19:43:25.764Z
Learning: When suggesting refactoring of build scripts, consider the possibility of nested `go.mod` files within subdirectories like `./cmd/`, and ensure that the proposed changes handle nested modules correctly.
Learnt from: amery
PR: darvaza-proxy/core#79
File: internal/build/gen_mk.sh:161-169
Timestamp: 2024-10-08T15:33:35.792Z
Learning: When suggesting refactoring of build scripts, consider the possibility of nested `go.mod` files within subdirectories like `./cmd/`, and ensure that the proposed changes handle nested modules correctly.
🔇 Additional comments (14)
testutils_test.go (14)

1-8: Package and imports look good.

The package declaration and imports are appropriate for the test utilities. All imports are from the standard library, adhering to the zero external dependencies guideline.


10-27: Excellent generic slice helper with comprehensive documentation.

The S function provides a clean, concise way to create test slices with proper type inference. The documentation includes excellent examples covering various use cases including empty slices and struct types.


29-50: Robust solution for type assertion safety.

The extractMsgAndArgs function effectively addresses the type assertion panics identified in past reviews. It safely extracts format strings using the comma-ok idiom, preventing runtime panics when msgAndArgs[0] is not a string.


52-71: Clean test case abstraction with proper helper marking.

The TestCase interface and RunTestCases function provide a nice abstraction for structured test execution. The implementation correctly uses t.Helper() to ensure proper test output attribution.


73-89: Generic assertion helper with safe message formatting.

The AssertEqual function provides type-safe equality checking for comparable types. The use of extractMsgAndArgs properly addresses the type assertion concerns from past reviews.


91-107: Comprehensive slice comparison using reflect.DeepEqual.

The AssertSliceEqual function correctly uses reflect.DeepEqual for thorough slice comparison, which handles nested structures and non-comparable types properly.


109-126: Well-structured error assertion with proper revive annotation.

The AssertError function provides a clean API for error checking with appropriate revive disable comment for the flag parameter. The delegation to helper functions maintains clean separation of concerns.


128-150: Proper error handling in assertion helpers.

Both assertExpectedError and assertNoError correctly handle the safe message extraction and provide meaningful error messages. The implementation properly addresses the type assertion safety concerns.


152-183: Robust panic testing with optional validation.

The AssertPanic function and validatePanicRecovery helper provide comprehensive panic testing. The use of reflect.DeepEqual for panic value comparison is appropriate, and the safe message extraction prevents type assertion panics.


185-204: Clean no-panic assertion implementation.

The AssertNoPanic function properly recovers from panics and uses safe message formatting. The implementation is consistent with other assertion helpers.


206-224: Boolean assertion with proper revive annotation.

The AssertBool function provides specialised boolean checking with appropriate revive disable comment and safe message handling.


226-242: Well-designed concurrent testing helper.

The RunConcurrentTest function provides a clean API for concurrent testing with proper error collection. The channel-based error handling is appropriate for gathering errors from multiple goroutines.


244-266: Proper goroutine management and error collection.

The runWorkers and collectErrors functions handle concurrent execution correctly:

  • Proper use of sync.WaitGroup for synchronisation
  • Channel closure after all workers complete
  • Early return on first error in collection

The use of range numWorkers is a nice Go 1.22+ feature for integer ranges.


268-285: Benchmark helper with proper timer management.

The RunBenchmark function correctly handles benchmark setup and timer management:

  • Setup phase runs before timer reset
  • Timer reset occurs after setup to exclude setup time
  • Proper use of b.Helper() for output attribution
✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch enhance-test-utilities

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai auto-generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@codecov
Copy link

codecov bot commented Jul 17, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

@deepsource-io
Copy link

deepsource-io bot commented Jul 17, 2025

Here's the code health analysis summary for commits f6adf21..9a9f0cc. View details on DeepSource ↗.

Analysis Summary

AnalyzerStatusSummaryLink
DeepSource Shell LogoShell✅ SuccessView Check ↗
DeepSource Go LogoGo✅ SuccessView Check ↗

💡 If you’re a repository administrator, you can configure the quality gates from the settings.

@amery amery requested a review from karasz July 17, 2025 14:16
@amery amery added enhancement New feature or request tests Test-related changes and improvements labels Jul 17, 2025
@amery amery self-assigned this Jul 17, 2025
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f6adf21 and aee1898.

📒 Files selected for processing (17)
  • AGENT.md (3 hunks)
  • addrport_test.go (1 hunks)
  • addrs_test.go (6 hunks)
  • as_test.go (8 hunks)
  • compounderror_test.go (16 hunks)
  • errors_test.go (2 hunks)
  • generics_test.go (5 hunks)
  • internal/build/cspell.json (2 hunks)
  • lists_test.go (1 hunks)
  • maps_test.go (25 hunks)
  • panic_test.go (7 hunks)
  • panicerror_test.go (4 hunks)
  • slices.go (1 hunks)
  • slices_test.go (5 hunks)
  • spinlock_test.go (5 hunks)
  • stack.go (1 hunks)
  • testutils_test.go (1 hunks)
🧰 Additional context used
📓 Path-based instructions (7)
**/*

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
internal/build/cspell.json

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*.go

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*.{md,go}

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*_test.go

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*.md

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
AGENT.md

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
🧠 Learnings (17)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Only use the Go standard library and minimal golang.org/x packages; zero external dependencies.
internal/build/cspell.json (10)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to internal/build/cspell.json : Add technical terms to internal/build/cspell.json for spelling and grammar tools.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*.{md,go} : Markdown and Go source files must be checked with CSpell for spelling (British English, custom word list).
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*.md : When editing Markdown files, ensure compliance with LanguageTool (articles, punctuation, hyphenation), CSpell (spelling), and markdownlint (formatting).
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*.go : Enforce strict linting rules via revive: max function length 40 lines, max function results 3, max arguments 5, cognitive complexity 7, cyclomatic complexity 10 (configured in internal/build/revive.toml).
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Only use the Go standard library and minimal golang.org/x packages; zero external dependencies.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: ALWAYS run `make tidy` before committing: Go code formatting, whitespace clean-up, Markdown files checked with CSpell, LanguageTool, and markdownlint.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*.go : Everything must be in the `core` package; do not create subpackages.
errors_test.go (4)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: amery
PR: darvaza-proxy/core#82
File: errors.go:22-23
Timestamp: 2024-10-11T13:59:15.993Z
Learning: `ErrNilReceiver`, defined in `errors.go`, is intended for use by other packages even if it's not used within the current codebase.
lists_test.go (5)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: amery
PR: darvaza-proxy/core#84
File: list.go:160-171
Timestamp: 2024-11-15T04:50:14.792Z
Learning: In the Go `core` package's `list.go` file, the method `unsafeForEachElement` in `List[T]` does not need to check if `l` is `nil` because all public methods that call it already perform this check.
Learnt from: amery
PR: darvaza-proxy/core#86
File: list.go:83-89
Timestamp: 2024-11-16T07:43:16.106Z
Learning: In `list.go`, the `List[T]` methods `Len` and `ForEach` handle a nil receiver gracefully.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
slices.go (1)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
addrport_test.go (3)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
panicerror_test.go (4)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: amery
PR: darvaza-proxy/core#86
File: list.go:32-36
Timestamp: 2024-11-16T05:20:11.432Z
Learning: In Go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as this will cause a runtime panic.
compounderror_test.go (5)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: amery
PR: darvaza-proxy/core#82
File: errors.go:22-23
Timestamp: 2024-10-11T13:59:15.993Z
Learning: `ErrNilReceiver`, defined in `errors.go`, is intended for use by other packages even if it's not used within the current codebase.
Learnt from: amery
PR: darvaza-proxy/core#86
File: list.go:32-36
Timestamp: 2024-11-16T05:20:11.432Z
Learning: In Go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as this will cause a runtime panic.
addrs_test.go (3)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
slices_test.go (3)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
AGENT.md (9)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to AGENT.md : Update AGENT.md to reflect any changes in development workflow or standards.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to README.md : Update README.md to reflect significant changes in functionality or API.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Only use the Go standard library and minimal golang.org/x packages; zero external dependencies.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*.go : Enforce strict linting rules via revive: max function length 40 lines, max function results 3, max arguments 5, cognitive complexity 7, cyclomatic complexity 10 (configured in internal/build/revive.toml).
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: ALWAYS run `make tidy` before committing: Go code formatting, whitespace clean-up, Markdown files checked with CSpell, LanguageTool, and markdownlint.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Always run `make tidy` before committing to ensure proper formatting.
as_test.go (5)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: amery
PR: darvaza-proxy/core#86
File: list.go:83-89
Timestamp: 2024-11-16T07:43:16.106Z
Learning: In `list.go`, the `List[T]` methods `Len` and `ForEach` handle a nil receiver gracefully.
Learnt from: amery
PR: darvaza-proxy/core#82
File: errors.go:22-23
Timestamp: 2024-10-11T13:59:15.993Z
Learning: `ErrNilReceiver`, defined in `errors.go`, is intended for use by other packages even if it's not used within the current codebase.
panic_test.go (3)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
generics_test.go (3)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
testutils_test.go (4)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Only use the Go standard library and minimal golang.org/x packages; zero external dependencies.
maps_test.go (5)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: amery
PR: darvaza-proxy/core#86
File: list.go:83-89
Timestamp: 2024-11-16T07:43:16.106Z
Learning: In `list.go`, the `List[T]` methods `Len` and `ForEach` handle a nil receiver gracefully.
Learnt from: amery
PR: darvaza-proxy/core#84
File: list.go:160-171
Timestamp: 2024-11-15T04:50:14.792Z
Learning: In the Go `core` package's `list.go` file, the method `unsafeForEachElement` in `List[T]` does not need to check if `l` is `nil` because all public methods that call it already perform this check.
spinlock_test.go (9)
Learnt from: amery
PR: darvaza-proxy/core#105
File: sync.go:11-12
Timestamp: 2025-04-17T20:14:08.093Z
Learning: In the darvaza.org/core module, the SpinLock type is being deprecated in favor of darvaza.org/x/sync/spinlock. The implementation must remain in place (not an alias) to avoid circular dependencies, as the new package likely imports from core.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: amery
PR: darvaza-proxy/core#86
File: list.go:32-36
Timestamp: 2024-11-16T05:20:11.432Z
Learning: In Go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as this will cause a runtime panic.
Learnt from: amery
PR: darvaza-proxy/core#86
File: list.go:83-89
Timestamp: 2024-11-16T07:43:16.106Z
Learning: In `list.go`, the `List[T]` methods `Len` and `ForEach` handle a nil receiver gracefully.
Learnt from: amery
PR: darvaza-proxy/core#82
File: errors.go:22-23
Timestamp: 2024-10-11T13:59:15.993Z
Learning: `ErrNilReceiver`, defined in `errors.go`, is intended for use by other packages even if it's not used within the current codebase.
Learnt from: amery
PR: darvaza-proxy/core#84
File: list.go:160-171
Timestamp: 2024-11-15T04:50:14.792Z
Learning: In the Go `core` package's `list.go` file, the method `unsafeForEachElement` in `List[T]` does not need to check if `l` is `nil` because all public methods that call it already perform this check.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Only use the Go standard library and minimal golang.org/x packages; zero external dependencies.
🧬 Code Graph Analysis (10)
errors_test.go (2)
testutils_test.go (2)
  • S (20-25)
  • AssertBool (186-195)
errors.go (2)
  • IsErrorFn (234-257)
  • IsErrorFn2 (265-291)
lists_test.go (2)
lists.go (2)
  • ListForEach (29-40)
  • ListForEachElement (43-55)
testutils_test.go (1)
  • S (20-25)
addrport_test.go (2)
testutils_test.go (1)
  • S (20-25)
addrport.go (1)
  • AddrPort (20-49)
panicerror_test.go (1)
testutils_test.go (1)
  • S (20-25)
compounderror_test.go (1)
testutils_test.go (1)
  • S (20-25)
addrs_test.go (1)
testutils_test.go (1)
  • S (20-25)
as_test.go (1)
testutils_test.go (1)
  • S (20-25)
panic_test.go (2)
testutils_test.go (2)
  • AssertEqual (55-64)
  • AssertError (94-101)
panic.go (1)
  • Recovered (8-11)
maps_test.go (2)
testutils_test.go (3)
  • AssertEqual (55-64)
  • S (20-25)
  • AssertSliceEqual (73-82)
maps.go (11)
  • SortedKeys (17-30)
  • SortedValuesUnlikelyCond (55-61)
  • MapListInsert (136-138)
  • MapListAppend (175-177)
  • MapListContainsFn (98-107)
  • MapListInsertUnique (154-158)
  • MapListAppendUnique (181-185)
  • MapListForEach (110-120)
  • MapListCopyFn (207-214)
  • MapAllListContainsFn (227-246)
  • MapListAppendUniqueFn (189-197)
spinlock_test.go (2)
testutils_test.go (6)
  • AssertEqual (55-64)
  • RunConcurrentTest (207-213)
  • AssertError (94-101)
  • AssertPanic (132-139)
  • AssertNoPanic (163-175)
  • RunBenchmark (249-256)
sync.go (1)
  • SpinLock (13-13)
🔇 Additional comments (50)
internal/build/cspell.json (1)

45-45: LGTM! Appropriate dictionary additions for test utilities.

The new words "govet", "linters", and "testutils" are relevant technical terms that align with the PR's focus on test infrastructure improvements and linting enhancements.

Also applies to: 52-52, 79-79

stack.go (1)

28-38: LGTM! Comment simplification improves clarity.

Removing explicit byte size annotations from struct field comments makes them more maintainable whilst retaining the alphabetical ordering information that's actually useful for developers.

slices.go (1)

282-286: LGTM! Consistent comment cleanup.

The removal of explicit byte size annotations from the sortable[T] struct comments aligns with the broader PR pattern of simplifying comments whilst maintaining useful information about field ordering.

testutils_test.go (10)

20-25: LGTM! Excellent generic slice helper implementation.

The S[T] function provides a concise way to create test slices with proper type inference. The zero-length slice handling is correct and the documentation clearly explains usage patterns.


27-46: LGTM! Clean TestCase interface design.

The TestCase interface and RunTestCases function provide good abstraction for structured test execution. Proper use of t.Helper() ensures clean test output.


55-64: LGTM! Robust generic assertion helper.

AssertEqual provides excellent error reporting with optional custom messages. The generic constraint and error formatting are well-implemented.


73-82: LGTM! Deep equality checking for slices.

AssertSliceEqual correctly uses reflect.DeepEqual for comprehensive slice comparison. The error messaging is clear and helpful.


94-123: LGTM! Well-structured error assertion with helper functions.

The AssertError function with its internal helpers assertExpectedError and assertNoError provides clean separation of concerns and consistent error reporting patterns.


132-154: LGTM! Comprehensive panic testing implementation.

AssertPanic with validatePanicRecovery provides robust panic testing with optional panic value validation. The defer/recover pattern is correctly implemented.


163-175: LGTM! Clean no-panic assertion.

AssertNoPanic provides the complementary functionality to AssertPanic with proper error reporting for unexpected panics.


186-195: LGTM! Specialised boolean assertion helper.

AssertBool provides targeted boolean assertion functionality with clear error messages and optional custom formatting.


207-237: LGTM! Excellent concurrent testing infrastructure.

The RunConcurrentTest function with its helper functions runWorkers and collectErrors provides a clean abstraction for concurrent testing. Proper use of sync.WaitGroup and error collection via channels.


249-256: LGTM! Proper benchmark helper implementation.

RunBenchmark correctly handles benchmark setup and timer management with the standard pattern of setup, reset timer, and execution loop.

generics_test.go (5)

10-10: LGTM! Field reordering for better alignment.

Moving the expected field to the first position in coalesceTestCase[T] likely improves memory layout and aligns with the PR's field alignment optimisation goals.


149-149: LGTM! Consistent field alignment optimisation.

The expected field reordering in coalescePointerTestCase[T] follows the same pattern as the generic test case, maintaining consistency across the codebase.


422-422: LGTM! Field reordering for memory efficiency.

Moving the cond boolean field to the last position in iifStringTestCase likely improves struct packing and memory efficiency.


483-485: LGTM! Consistent field alignment across IIf test cases.

The field reordering in iifPointerTestCase maintains consistency with other IIf test case structs, placing the boolean cond field at the end for better memory layout.


562-562: LGTM! Final field alignment consistency.

The cond field placement in iifStructTestCase completes the consistent field ordering pattern across all IIf test case structures.

panicerror_test.go (1)

82-82: LGTM! Consistent adoption of ST helper function.

The changes correctly replace explicit slice literals with the generic ST helper function, improving code consistency and maintainability. The removal of specific byte counts from struct field comments (line 82) also makes the code more maintainable.

Also applies to: 150-150, 156-156, 203-203, 404-404

errors_test.go (1)

24-29: LGTM! Proper adoption of test helper functions.

The changes correctly implement the new test utilities:

  • ST helper function for concise slice creation
  • AssertBool helper for boolean assertions with clear error messages

The explicit type parameter usage (e.g., S[error]()) is appropriate for empty slices and mixed content scenarios.

Also applies to: 33-33, 59-64, 68-69

addrport_test.go (1)

228-228: LGTM! Consistent usage of ST for byte slices.

The changes correctly replace explicit byte slice literals with the Sbyte helper function, maintaining consistency with the broader refactoring effort whilst preserving the test logic for invalid IP address scenarios.

Also applies to: 234-234

addrs_test.go (1)

12-20: LGTM! Comprehensive adoption of ST helper across multiple types.

The changes demonstrate excellent consistency in adopting the ST helper function across various slice types (string, netip.Addr, net.Addr). The explicit type specifications (e.g., S[string](), S[netip.Addr]) and the use of netip.Addr{} for invalid addresses improve code clarity. The comment updates removing specific byte counts also enhance maintainability.

Also applies to: 183-190, 327-327, 433-441, 516-524, 532-537, 585-590

as_test.go (2)

11-11: Good simplification of field comments.

The removal of explicit size annotations from the struct field comments improves readability whilst maintaining clarity about the field purposes.

Also applies to: 15-15


295-295: Excellent adoption of the ST helper function.

The consistent replacement of explicit slice literals with calls to the generic S() helper function improves test code readability and maintainability. The usage correctly handles both typed empty slices (S[string]()) and value-filled slices (S("a", "b", "c")).

Also applies to: 300-300, 320-320, 343-343, 446-446, 456-456, 462-462, 468-468, 474-474, 484-484

compounderror_test.go (1)

18-18: Excellent systematic adoption of the ST helper.

The consistent replacement of explicit []error slice literals with calls to the generic S() helper function throughout the test cases improves code consistency and readability. The usage correctly handles both populated error slices (S(errors.New("first error"))) and empty typed slices (S[error]()).

Also applies to: 23-23, 28-28, 33-33, 38-38, 60-63, 80-83, 108-108, 118-118, 123-123, 153-153, 163-163, 168-168, 208-209, 214-215, 220-221, 226-227, 262-262, 263-263, 304-304, 306-306, 336-336, 345-345, 354-354, 363-363, 372-372, 468-468

slices_test.go (2)

20-20: Excellent adoption of standardised assertion helpers.

The replacement of manual conditional checks and error calls with helper assertion functions like AssertSliceEqual, AssertBool, and AssertEqual significantly improves test consistency and readability. The assertion helpers provide clearer error messages and reduce boilerplate code whilst maintaining the same test logic.

Also applies to: 62-62, 66-66, 71-71, 72-72, 77-77, 78-78, 109-109, 134-134, 153-153, 154-154, 157-157


29-29: Proper usage of ST helper for test data.

The consistent replacement of explicit slice literals with calls to the generic S() helper function in the test data definitions improves maintainability and follows the established testing patterns.

Also applies to: 30-30, 32-35, 36-36, 38-38, 39-39

spinlock_test.go (4)

41-41: Excellent adoption of assertion helpers.

The replacement of manual conditional checks and error calls with standardised assertion functions like AssertEqual, AssertError, AssertPanic, and AssertNoPanic significantly improves test consistency and provides clearer, more informative error messages.

Also applies to: 96-96, 104-104, 151-151, 153-153, 167-167, 173-173, 179-179, 205-205, 208-208


79-94: Proper usage of RunConcurrentTest helper.

The replacement of manual goroutine and wait group management with the RunConcurrentTest helper function simplifies concurrent testing whilst maintaining the same test logic. The error handling approach with return values from worker functions is cleaner than manual synchronisation.

Also applies to: 195-203


212-225: Good adoption of RunBenchmark helper.

The use of the RunBenchmark helper with setup and execution closures provides a cleaner structure for benchmark tests, separating initialisation from the actual benchmark execution.

Also applies to: 229-238


240-257: Well-structured benchmark helper function.

The runContentionBenchmark helper function properly encapsulates the contended benchmark logic, making the main benchmark function cleaner and more focused.

AGENT.md (2)

168-228: Excellent comprehensive documentation of test helper functions.

The new "Test Helper Functions" section provides thorough documentation of the helper functions introduced in testutils_test.go. The documentation includes:

  • Clear descriptions of each helper function's purpose
  • Practical usage examples showing before/after comparisons
  • Explanation of the benefits (consistent error messages, reduced boilerplate, better maintainability)
  • Proper categorisation of helpers (slice creation, assertions, advanced helpers)

The examples accurately demonstrate how the helpers simplify test code and improve consistency across the codebase.


350-361: Good punctuation and formatting improvements.

The addition of periods at the end of bullet points and clarification of sentence endings improves consistency and readability throughout the documentation without changing the semantic content.

Also applies to: 407-410, 414-419

maps_test.go (8)

12-13: Field alignment optimisation looks correct.

The reordering of fields in the struct follows Go best practices by placing larger fields (string) before smaller ones (int) to improve memory alignment and reduce padding.


44-44: Good use of the generic AssertEqual helper.

The refactoring from manual assertion to AssertEqual improves consistency and provides better error messages whilst maintaining the same test logic.


78-78: Excellent adoption of the ST helper for slice creation.

The conversion from slice literals to S[T]() calls reduces boilerplate and aligns with the project's standardisation efforts. The empty slice creation using S[string]() is particularly clean.

Also applies to: 83-83, 88-88, 93-93, 98-98


106-106: AssertSliceEqual usage is correct and improves readability.

The replacement of manual slice comparisons with AssertSliceEqual provides better error messages and standardises the assertion pattern throughout the test suite.

Also applies to: 121-121, 158-158, 218-218


118-118: Consistent use of S() helper for test data.

The adoption of S() for creating test slices is consistent with the project's guidelines and reduces boilerplate code effectively.

Also applies to: 231-231, 247-247


239-239: Good use of AssertEqual for boolean and length comparisons.

The helper function usage maintains the original test semantics whilst providing clearer error messages when assertions fail.

Also applies to: 243-243


300-301: Comprehensive and correct adoption of assertion helpers.

The systematic replacement of manual assertions with AssertEqual throughout the test functions maintains the original test logic whilst improving consistency and error reporting. The helper functions are used correctly with appropriate error messages.

Also applies to: 349-349, 364-365, 372-372, 381-382, 386-387, 389-390, 403-404, 439-440, 443-444, 447-448, 456-456, 460-460, 464-464, 472-472, 476-476, 480-480, 507-508, 516-516, 595-595, 598-598, 622-622, 631-631, 636-637, 656-658, 665-665, 678-678, 710-710, 716-716, 720-720, 736-736, 746-746, 761-761, 770-770, 782-782, 790-790


429-429: Proper field alignment optimisation in struct.

The reordering of fields in the customType struct follows Go best practices by placing the int field after the string field. This optimisation reduces memory padding and improves struct layout efficiency.

Also applies to: 433-434

panic_test.go (9)

9-9: Field alignment optimisation improves memory layout.

The addition of the comment clarifies the intention behind field ordering, placing interface types and strings before smaller boolean fields to reduce memory padding.


76-76: Correct use of AssertEqual for string comparisons.

The replacement of manual t.Fatalf calls with AssertEqual maintains the original test logic whilst providing better error messages and consistency across the test suite.

Also applies to: 82-82, 87-87


165-165: Good use of AssertError for error expectation validation.

The AssertError helper correctly validates whether an error is expected or not, replacing manual error checking logic whilst maintaining the same test semantics.


167-175: Improved error handling logic with clearer structure.

The refactored conditional logic for panic recovery validation is more readable and maintains the original test intent. The type assertion and nil check for recovered values are properly preserved.


230-230: Consistent error expectation handling.

The use of AssertError in the catcherTryTestCase test maintains the original logic whilst standardising the error checking pattern.


238-240: Cleaner conditional logic for panic recovery checks.

The refactored logic maintains the original test semantics whilst improving readability. The error message format is preserved for consistency.


269-269: Appropriate use of AssertEqual for error message validation.

The helper function usage correctly validates the panic error message whilst maintaining the original test logic.


351-351: Consistent assertion pattern maintained.

The use of AssertError in the catchTestCase test follows the established pattern and maintains the original error checking logic.


381-381: Proper error and value assertions in panic recovery tests.

The combination of AssertError for error expectation and AssertEqual for value comparisons maintains the original test logic whilst providing better error messages and consistency.

Also applies to: 389-389, 394-394

amery added 5 commits July 17, 2025 15:19
- Reorder coalesceTestCase fields: expected, name, inputs (better alignment)
- Reorder coalescePointerTestCase fields: expected, name, inputs (better alignment)
- Reorder iifStringTestCase fields: name, yes, no, expected, cond (better alignment)
- Reorder iifPointerTestCase fields: yes, no, expected, name, cond (better alignment)
- Reorder iifStructTestCase fields: name, yes, no, expected, cond (better alignment)

Field alignment optimization improves memory efficiency for test structures.
All struct initializations remain compatible with new field ordering.

Signed-off-by: Alejandro Mery <amery@apptly.co>
- Reorder keysTestCase fields: input, name, expected (better alignment)
- Reorder customType fields: name, id (better alignment)
- Update struct literals to use named field initialization
- Maintain compatibility with reordered field layout

Field alignment optimization improves memory efficiency for test structures.
All struct initializations updated to work with new field ordering.

Signed-off-by: Alejandro Mery <amery@apptly.co>
- Add "govet" to internal/build/cspell.json
- Add "linters" to internal/build/cspell.json
- Fix spelling check failures in golangci-lint documentation
- Support technical terms used in AGENT.md configuration sections

Technical linter names are now recognized in spell checking.
Enables clean documentation of golangci-lint configuration.

Signed-off-by: Alejandro Mery <amery@apptly.co>
- Add missing periods to bullet points in field alignment section
- Fix numbered list punctuation for golangci-lint schema issues
- Ensure consistent punctuation in resolution status section
- Satisfy markdownlint requirements for list formatting

All documentation lists now follow consistent punctuation standards.
Markdownlint validation passes without punctuation warnings.

Signed-off-by: Alejandro Mery <amery@apptly.co>
…ments

- Remove hard-coded byte counts from struct field comments
- Keep field ordering information without platform-specific sizes
- Maintain field alignment rationale in comments
- Apply changes to Frame, sortable, and test case structs

Field alignment comments now focus on ordering without stale byte counts.
Comments remain informative while avoiding platform-specific assumptions.

Signed-off-by: Alejandro Mery <amery@apptly.co>
@amery amery force-pushed the enhance-test-utilities branch from aee1898 to 2129f1d Compare July 17, 2025 15:26
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 7

🧹 Nitpick comments (1)
testutils_test.go (1)

257-257: Add missing newline at end of file.

The file must end with a newline according to the coding guidelines.

 }
+
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between aee1898 and 2129f1d.

📒 Files selected for processing (17)
  • AGENT.md (3 hunks)
  • addrport_test.go (1 hunks)
  • addrs_test.go (6 hunks)
  • as_test.go (8 hunks)
  • compounderror_test.go (16 hunks)
  • errors_test.go (2 hunks)
  • generics_test.go (5 hunks)
  • internal/build/cspell.json (2 hunks)
  • lists_test.go (1 hunks)
  • maps_test.go (29 hunks)
  • panic_test.go (7 hunks)
  • panicerror_test.go (4 hunks)
  • slices.go (1 hunks)
  • slices_test.go (5 hunks)
  • spinlock_test.go (5 hunks)
  • stack.go (1 hunks)
  • testutils_test.go (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (16)
  • internal/build/cspell.json
  • stack.go
  • slices.go
  • panicerror_test.go
  • lists_test.go
  • as_test.go
  • addrs_test.go
  • addrport_test.go
  • AGENT.md
  • maps_test.go
  • errors_test.go
  • panic_test.go
  • slices_test.go
  • generics_test.go
  • spinlock_test.go
  • compounderror_test.go
🧰 Additional context used
📓 Path-based instructions (4)
**/*.go

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*_test.go

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*.{md,go}

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Only use the Go standard library and minimal golang.org/x packages; zero external dependencies.
testutils_test.go (4)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Only use the Go standard library and minimal golang.org/x packages; zero external dependencies.
🔇 Additional comments (5)
testutils_test.go (5)

1-8: Package declaration and imports look correct.

The package is properly declared as core and all imports are from the standard library with no external dependencies, following the project guidelines.


10-25: Excellent slice creation helper implementation.

The S[T] function is well-designed with proper generic constraints and clear documentation. It will significantly reduce boilerplate in table-driven tests as intended.


27-46: Well-designed TestCase interface and runner.

The TestCase interface and RunTestCases function provide a clean abstraction for structured test execution, properly using t.Helper() and t.Run().


197-237: Excellent concurrent testing implementation.

The concurrent testing utilities are well-designed with proper goroutine management, synchronization using sync.WaitGroup, and clean error collection through channels. The separation into helper functions improves maintainability.


239-256: Well-designed benchmark helper.

The RunBenchmark function provides a clean abstraction for benchmark testing with proper timer management and setup/execution separation.

amery added 2 commits July 17, 2025 20:25
- Create testutils_test.go with generic S[T]() helper function
- Provide concise syntax for test slice creation: S(1, 2, 3) vs []int{1, 2, 3}
- Support empty slice creation with type specification: S[int]()
- Add comprehensive documentation with usage examples

Test slice creation is now more concise and readable.
Foundation for converting all test slice literals to use helper function.

Signed-off-by: Alejandro Mery <amery@apptly.co>
- Replace 119 slice literals across 9 test files with S[T]() helper calls
- Convert []int{1, 2, 3} to S(1, 2, 3) for improved readability
- Convert []string{} to S[string]() for type-safe empty slices
- Standardize slice creation syntax across all test files

Files updated:
- addrport_test.go: 2 literals → S() calls
- addrs_test.go: 8 literals → S() calls
- as_test.go: 10 literals → S() calls
- compounderror_test.go: 21 literals → S() calls
- errors_test.go: 12 literals → S() calls
- lists_test.go: 6 literals → S() calls
- maps_test.go: 8 literals → S() calls
- panicerror_test.go: 4 literals → S() calls
- slices_test.go: 9 literals → S() calls

All tests maintain functionality while improving code consistency.

Signed-off-by: Alejandro Mery <amery@apptly.co>
@amery amery force-pushed the enhance-test-utilities branch from 2129f1d to 1d78987 Compare July 17, 2025 20:25
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

♻️ Duplicate comments (7)
testutils_test.go (7)

57-66: Fix potential panic in type assertion.

The type assertion msgAndArgs[0].(string) on line 62 could panic if the first argument is not a string. This is a duplicate of a previously identified issue.

-		if len(msgAndArgs) > 0 {
-			msg = fmt.Sprintf(msgAndArgs[0].(string), msgAndArgs[1:]...) + ": " + msg
-		}
+		if len(msgAndArgs) > 0 {
+			if format, ok := msgAndArgs[0].(string); ok {
+				msg = fmt.Sprintf(format, msgAndArgs[1:]...) + ": " + msg
+			}
+		}

75-84: Fix potential panic in type assertion.

The type assertion msgAndArgs[0].(string) on line 80 could panic if the first argument is not a string. This is a duplicate of a previously identified issue.

-		if len(msgAndArgs) > 0 {
-			msg = fmt.Sprintf(msgAndArgs[0].(string), msgAndArgs[1:]...) + ": " + msg
-		}
+		if len(msgAndArgs) > 0 {
+			if format, ok := msgAndArgs[0].(string); ok {
+				msg = fmt.Sprintf(format, msgAndArgs[1:]...) + ": " + msg
+			}
+		}

105-114: Fix potential panic in type assertion.

The type assertion msgAndArgs[0].(string) on line 110 could panic if the first argument is not a string. This is a duplicate of a previously identified issue.

-		if len(msgAndArgs) > 0 {
-			msg = fmt.Sprintf(msgAndArgs[0].(string), msgAndArgs[1:]...)
-		}
+		if len(msgAndArgs) > 0 {
+			if format, ok := msgAndArgs[0].(string); ok {
+				msg = fmt.Sprintf(format, msgAndArgs[1:]...)
+			}
+		}

116-125: Fix potential panic in type assertion.

The type assertion msgAndArgs[0].(string) on line 121 could panic if the first argument is not a string. This is a duplicate of a previously identified issue.

-		if len(msgAndArgs) > 0 {
-			msg = fmt.Sprintf(msgAndArgs[0].(string), msgAndArgs[1:]...) + ": %v"
-		}
+		if len(msgAndArgs) > 0 {
+			if format, ok := msgAndArgs[0].(string); ok {
+				msg = fmt.Sprintf(format, msgAndArgs[1:]...) + ": %v"
+			}
+		}

134-156: Fix potential panic in type assertion.

The type assertion msgAndArgs[0].(string) on line 148 in validatePanicRecovery could panic if the first argument is not a string. This is a duplicate of a previously identified issue.

-		if len(msgAndArgs) > 0 {
-			msg = fmt.Sprintf(msgAndArgs[0].(string), msgAndArgs[1:]...)
-		}
+		if len(msgAndArgs) > 0 {
+			if format, ok := msgAndArgs[0].(string); ok {
+				msg = fmt.Sprintf(format, msgAndArgs[1:]...)
+			}
+		}

165-177: Fix potential panic in type assertion.

The type assertion msgAndArgs[0].(string) on line 171 could panic if the first argument is not a string. This is a duplicate of a previously identified issue.

-			if len(msgAndArgs) > 0 {
-				msg = fmt.Sprintf(msgAndArgs[0].(string), msgAndArgs[1:]...) + ": " + msg
-			}
+			if len(msgAndArgs) > 0 {
+				if format, ok := msgAndArgs[0].(string); ok {
+					msg = fmt.Sprintf(format, msgAndArgs[1:]...) + ": " + msg
+				}
+			}

187-197: Fix potential panic in type assertion.

The type assertion msgAndArgs[0].(string) on line 193 could panic if the first argument is not a string. This is a duplicate of a previously identified issue.

-		if len(msgAndArgs) > 0 {
-			msg = fmt.Sprintf(msgAndArgs[0].(string), msgAndArgs[1:]...) + ": " + msg
-		}
+		if len(msgAndArgs) > 0 {
+			if format, ok := msgAndArgs[0].(string); ok {
+				msg = fmt.Sprintf(format, msgAndArgs[1:]...) + ": " + msg
+			}
+		}
🧹 Nitpick comments (1)
testutils_test.go (1)

259-259: Missing final newline.

The file should end with a newline character according to the coding guidelines.

+
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2129f1d and 1d78987.

📒 Files selected for processing (14)
  • AGENT.md (3 hunks)
  • addrport_test.go (1 hunks)
  • addrs_test.go (6 hunks)
  • as_test.go (8 hunks)
  • compounderror_test.go (16 hunks)
  • errors_test.go (2 hunks)
  • internal/build/cspell.json (2 hunks)
  • lists_test.go (1 hunks)
  • maps_test.go (29 hunks)
  • panic_test.go (7 hunks)
  • panicerror_test.go (4 hunks)
  • slices_test.go (5 hunks)
  • spinlock_test.go (5 hunks)
  • testutils_test.go (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (13)
  • internal/build/cspell.json
  • errors_test.go
  • lists_test.go
  • panicerror_test.go
  • maps_test.go
  • addrport_test.go
  • addrs_test.go
  • compounderror_test.go
  • panic_test.go
  • spinlock_test.go
  • AGENT.md
  • slices_test.go
  • as_test.go
🧰 Additional context used
📓 Path-based instructions (4)
**/*.go

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*_test.go

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
**/*.{md,go}

Instructions used from:

Sources:
📄 CodeRabbit Inference Engine

  • AGENT.md
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Only use the Go standard library and minimal golang.org/x packages; zero external dependencies.
testutils_test.go (7)
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Helper functions like `S[T]()` should be used to create test slices in Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Comprehensive coverage for generic functions is expected in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Applies to **/*_test.go : Table-driven tests are preferred for Go tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-10T13:13:22.040Z
Learning: Only use the Go standard library and minimal golang.org/x packages; zero external dependencies.
Learnt from: amery
PR: darvaza-proxy/core#86
File: list.go:32-36
Timestamp: 2024-11-16T05:20:11.432Z
Learning: In Go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as this will cause a runtime panic.
Learnt from: amery
PR: darvaza-proxy/core#79
File: internal/build/gen_mk.sh:161-169
Timestamp: 2024-10-01T19:43:25.764Z
Learning: When suggesting refactoring of build scripts, consider the possibility of nested `go.mod` files within subdirectories like `./cmd/`, and ensure that the proposed changes handle nested modules correctly.
Learnt from: amery
PR: darvaza-proxy/core#79
File: internal/build/gen_mk.sh:161-169
Timestamp: 2024-10-08T15:33:35.792Z
Learning: When suggesting refactoring of build scripts, consider the possibility of nested `go.mod` files within subdirectories like `./cmd/`, and ensure that the proposed changes handle nested modules correctly.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
  • GitHub Check: multi-go (1.24)
  • GitHub Check: multi-go (1.23)
  • GitHub Check: test
  • GitHub Check: race
  • GitHub Check: make (1.23)
  • GitHub Check: make (1.24)
🔇 Additional comments (7)
testutils_test.go (7)

1-8: Package declaration and imports look good.

The file correctly uses the core package and imports only standard library packages, adhering to the coding guidelines.


10-27: Excellent generic slice helper implementation.

The S[T] function provides a clean, type-safe way to create slices and aligns with the retrieved learning that helper functions like S[T]() should be used in Go tests. The comprehensive documentation with examples is particularly valuable.


29-48: Well-designed TestCase interface and runner.

The TestCase interface and RunTestCases function provide excellent abstraction for table-driven tests, which aligns with the preferred testing pattern mentioned in the coding guidelines.


95-96: Appropriate use of revive disable comment.

The revive:disable-next-line:flag-parameter comment is correctly used for the expectError bool parameter, which is a legitimate design choice for this assertion helper.


209-215: Well-structured concurrent testing helper.

The RunConcurrentTest function provides excellent abstraction for concurrent testing patterns with proper error collection and synchronisation.


217-239: Excellent separation of concerns in worker management.

The runWorkers and collectErrors functions provide clean separation of concerns for goroutine management and error collection. The use of WaitGroup and proper channel closure is correctly implemented.


251-258: Proper benchmark helper implementation.

The RunBenchmark function correctly handles benchmark timing with b.ResetTimer() and provides a clean interface for setup and execution phases.

amery added 2 commits July 17, 2025 22:55
- Add AssertEqual, AssertSliceEqual, AssertError assertion helpers
- Add AssertPanic, AssertNoPanic, AssertBool for specialized testing
- Create RunConcurrentTest for standardized goroutine testing patterns
- Add RunBenchmark for setup/execution phase benchmark helpers
- Expand testutils_test.go with 238 lines of helper functions
- Update AGENT.md with comprehensive test helper documentation
- Add "testutils" to cspell dictionary for spell checking

Test file improvements:
- maps_test.go: 204 lines → 133 lines (reduced boilerplate)
- panic_test.go: 74 lines → 45 lines (simplified assertions)
- slices_test.go: 47 lines → 32 lines (cleaner tests)
- spinlock_test.go: 151 lines → 118 lines (standardized concurrency)
- errors_test.go: 9 lines → 6 lines (assertion helpers)

Net change: +456 lines utility functions, -329 lines test boilerplate.
Test maintainability significantly improved with standardized patterns.

Signed-off-by: Alejandro Mery <amery@apptly.co>
- Add sliceReverseTestCase struct with name, input, and expected fields
- Implement test(t) method following established table-driven patterns
- Define test cases with descriptive names outside function
- Use t.Run() for proper subtest execution and hierarchy
- Utilize AssertSliceEqual helper for cleaner assertions
- Maintain all existing test coverage while improving organization

Test structure now aligns with codebase patterns and improves readability.
Proper subtest naming enables better test failure identification.

Signed-off-by: Alejandro Mery <amery@apptly.co>
@amery amery force-pushed the enhance-test-utilities branch from 1d78987 to 9a9f0cc Compare July 17, 2025 23:01
Copy link
Contributor

@karasz karasz left a comment

Choose a reason for hiding this comment

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

LGTM

@karasz karasz merged commit 2fec807 into main Jul 18, 2025
17 checks passed
@karasz karasz deleted the enhance-test-utilities branch July 18, 2025 16:38
@amery
Copy link
Contributor Author

amery commented Jul 18, 2025

v0.17.4 tagged

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

Labels

enhancement New feature or request tests Test-related changes and improvements

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants