Transform testing infrastructure to public API, add Must/Maybe utilities #131
Conversation
WalkthroughThis update introduces a comprehensive, generic testing utility package ( Changes
Sequence Diagram(s)sequenceDiagram
participant TestRunner as Test Runner
participant TestCase as TestCase (Name, Test)
participant T as T (interface)
participant MockT as MockT
participant Assertion as Assertion Helpers
TestRunner->>TestCase: RunTestCases(t, cases)
loop For each case
TestRunner->>TestCase: t.Run(Name(), Test)
TestCase->>T: Test(t)
TestCase->>Assertion: Use assertion helpers (e.g., AssertEqual)
Assertion->>T: Report/log result
end
TestRunner->>T: Collect and report results
sequenceDiagram
participant User as User Code
participant Must as Must/Maybe/MustOK/MaybeOK
participant PanicError as PanicError (with stack trace)
User->>Must: Must(value, err)
alt err != nil
Must->>PanicError: Panic with wrapped error and stack trace
else
Must->>User: Return value
end
Estimated code review effort🎯 5 (Critical) | ⏱️ ~90+ minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
Here's the code health analysis summary for commits Analysis Summary
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
PR Reviewer Guide 🔍(Review updated until commit a79bb52)Here are some key observations to aid the review process:
|
PR Code Suggestions ✨Explore these optional code suggestions:
|
||||||||||||||||
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🔭 Outside diff range comments (6)
.vscode/cspell.json (1)
1-2: Configuration file is invalid JSON – CSpell will not load itLine 1 is a bare path string, and Line 2 starts key/value pairs without an opening
{.
CSpell expects a valid JSON object. The simplest valid form to delegate to the internal config is:-../internal/build/cspell.json - "$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json", +{ + "extends": "../internal/build/cspell.json", + "$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json",…followed by the rest of the keys and a matching closing
}at the end.Until this is fixed, VS Code and CI spelling checks will silently ignore your settings.
waitgroup_test.go (2)
292-293: Use assertion helpers instead of t.Error().For consistency with the refactored tests, use
AssertErrororAssertNilinstead of direct error reporting.- t.Error("Done channel closed too early") + AssertNil(t, "done channel", "should not be closed early")
365-372: Replace t.Errorf() with assertion helpers throughout TestWaitGroupConcurrency.Update the error assertions to use the new testing framework helpers.
- if err != nil { - t.Errorf("Expected no error, got: %v", err) - } + AssertNoError(t, err, "concurrent workers") expected := int64(numWorkers * numIterations) - if counter != expected { - t.Errorf("Expected counter %d, got %d", expected, counter) - } + AssertEqual(t, expected, counter, "counter value")panicerror_test.go (2)
130-139: Refactor to use assertion helpers for consistency.Replace t.Fatalf calls with the standardised assertion helpers.
if tc.expectUnwrap { - if unwrapped == nil { - t.Fatalf("expected unwrapped error, got nil") - } - if unwrapped.Error() != tc.expectedError { - t.Fatalf("expected unwrapped error '%s', got '%s'", tc.expectedError, unwrapped.Error()) - } - } else if unwrapped != nil { - t.Fatalf("expected nil unwrapped, got %v", unwrapped) + AssertNotNil(t, unwrapped, "unwrapped error") + AssertEqual(t, tc.expectedError, unwrapped.Error(), "unwrapped error message") + } else { + AssertNil(t, unwrapped, "unwrapped") }
174-184: Use assertion helpers instead of t.Fatalf.Update to use the new testing framework's assertion functions.
// Test Error method errorStr := pe.Error() expectedError := fmt.Sprintf("panic: %s", tc.expected) - if errorStr != expectedError { - t.Fatalf("expected error '%s', got '%s'", expectedError, errorStr) - } + AssertEqual(t, expectedError, errorStr, "error string") // Test that payload is an error - if _, ok := pe.Recovered().(error); !ok { - t.Fatalf("expected error payload, got %T", pe.Recovered()) - } + _, ok := AssertTypeIs[error](t, pe.Recovered(), "payload type")errgroup_test.go (1)
46-57: Use assertion helpers for consistency.Replace direct error reporting with the standardised assertion helpers.
- if eg.Parent != expectedParent { - t.Errorf("Expected Parent %v, got %v", expectedParent, eg.Parent) - } + AssertEqual(t, expectedParent, eg.Parent, "Parent context") - if eg.ctx == nil { - t.Error("Expected ctx to be initialized") - } + AssertNotNil(t, eg.ctx, "context") - if eg.cancel == nil { - t.Error("Expected cancel function to be initialized") - } + AssertNotNil(t, eg.cancel, "cancel function")
🧹 Nitpick comments (12)
.vscode/settings.json (1)
1-1: Empty settings file can be deleted to reduce noiseWith CSpell now configured via
.vscode/cspell.json, an emptysettings.jsonprovides no value and will be created automatically by VS Code if ever needed. Consider removing the file altogether.internal/build/cspell.json (1)
90-94: Maintain alphabetical ordering of custom words to minimise merge painThe newly-added entries (
Atoi,conn,Logf,mykey,strconv) are appended out of order. Keeping the list sorted eases future look-ups and reduces merge conflicts.- "waitgroup", - "Logf", - "mykey", - "strconv", - "Atoi", - "conn", + "Atoi", + "conn", + "Logf", + "mykey", + "strconv", + "waitgroup",README.md (1)
210-217: Vary repetitive bullet wording to satisfy LanguageTool rule.Three successive bullets begin with “returns …”. Re-phrase one or two of them (e.g. “Obtains…” / “Produces…”) or merge sentences to avoid the ENGLISH_WORD_REPEAT_BEGINNING_RULE violation.
This keeps the document clean and passes the mandatory LanguageTool gate.errors_test.go (1)
67-70: Assertion prefixes exceed recommended length.Prefixes like
"IsErrorFn2 is"/"IsErrorFn2 known"are four words.
Guidelines in TESTING.md recommend 1-3 words. Consider shortening to"is"and"known"for cleaner logs.maps_test.go (2)
781-814: Benchmarks bypass the newRunBenchmarkhelper.For consistency with the freshly introduced benchmarking API, wrap the manual benchmark loops with
core.RunBenchmark:-func BenchmarkKeys(b *testing.B) { - m := make(map[string]int) - ... - for i := 0; i < b.N; i++ { - _ = Keys(m) - } -} +func BenchmarkKeys(b *testing.B) { + m := prepareKeysMap() // extract setup + _ = core.RunBenchmark(b, nil, func(_ any) { + _ = Keys(m) + }) +}This keeps all benchmarks uniform and automatically enforces the setup/execution separation described in TESTING.md.
355-384: Long assertion prefixes.Messages such as
"list length after append"and"front value"exceed the 1-3-word guideline. Trim to simply"len"/"front"/"back"to keep logs concise.TESTING_core.md (1)
1-33: Minor style: bullets should end with full stops.A few list items (e.g. in Generic Function Testing and Context Key Testing) miss terminal periods, violating the documentation style guide. Please add trailing full stops.
TESTING.md (2)
439-444: Grammar nit – “prefer to use”.LanguageTool flags “Prefer table-driven tests over …”.
Change to “Prefer to use table-driven tests …” for correct idiom.
96-101: Ensure all bullet items finish with a period.A few bullets in the Prefix Guidelines list have no trailing full stop. Add them to comply with the docs style checklist.
waitgroup_test.go (1)
63-66: Consider increasing the sleep duration for more reliable async error handling.The 1 millisecond delay might be insufficient on heavily loaded systems or in CI environments. Consider increasing it to at least 10-50ms for more reliable async error detection.
- time.Sleep(1 * time.Millisecond) + time.Sleep(10 * time.Millisecond)panicerror_test.go (1)
80-81: Use assertion helpers instead of t.Fatalf for consistency.Replace t.Fatalf with AssertTypeIs for type assertion consistency.
- t.Fatalf("expected error type for string payload, got %T", recovered) + _, ok := AssertTypeIs[error](t, recovered, "string payload type") + if !ok { + return + }errgroup_test.go (1)
245-247: Use AssertPanic for panic testing.The deferred recover pattern can be replaced with AssertPanic.
- defer func() { - if r := recover(); r == nil { - t.Error("Expected panic for nil run function") - } - }() - eg.GoCatch(tc.runFunc, tc.catchFunc) + AssertPanic(t, func() { eg.GoCatch(tc.runFunc, tc.catchFunc) }, nil, "nil run function")
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (25)
.vscode/cspell.json(1 hunks).vscode/settings.json(1 hunks)AGENT.md(2 hunks)README.md(8 hunks)TESTING.md(1 hunks)TESTING_core.md(1 hunks)addrs_test.go(2 hunks)as_test.go(6 hunks)context_test.go(10 hunks)errgroup_test.go(4 hunks)errors_test.go(11 hunks)internal/build/cspell.json(1 hunks)lists_test.go(14 hunks)maps_test.go(25 hunks)panic.go(1 hunks)panic_test.go(8 hunks)panicerror_test.go(2 hunks)slices_test.go(12 hunks)spinlock_test.go(5 hunks)stack_test.go(8 hunks)testing.go(1 hunks)testing_test.go(1 hunks)testutils_test.go(0 hunks)waitgroup_test.go(4 hunks)zero_test.go(2 hunks)
💤 Files with no reviewable changes (1)
- testutils_test.go
🧰 Additional context used
📓 Path-based instructions (5)
**/*
📄 CodeRabbit Inference Engine (AGENT.md)
**/*: Remove trailing whitespace from all text files.
Ensure files end with a newline.
Files:
internal/build/cspell.jsonspinlock_test.goslices_test.goAGENT.mdcontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.gopanic.goTESTING.mdmaps_test.gowaitgroup_test.goREADME.mdTESTING_core.mdtesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gotesting.gozero_test.go
**/*.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.go: Enforce strict linting rules via revive with configuration ininternal/build/revive.toml.
Max function length: 40 lines.
Max function results: 3.
Max arguments: 5.
Cognitive complexity: 7.
Cyclomatic complexity: 10.
Field alignment optimization for struct definitions using thefieldalignmenttool.
Files:
spinlock_test.goslices_test.gocontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.gopanic.gomaps_test.gowaitgroup_test.gotesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gotesting.gozero_test.go
**/*_test.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*_test.go: Use test helper functions defined intestutils_test.goto reduce boilerplate and improve test consistency.
UseAssertEqual[T](t, expected, actual, msg...)for generic value comparison in tests.
UseAssertSliceEqual[T](t, expected, actual, msg...)for slice comparison in tests.
UseAssertError(t, err, expectError, msg...)for standardized error expectation checking in tests.
UseAssertBool(t, actual, expected, msg...)for boolean assertions in tests.
UseAssertPanic(t, fn, expectedPanic, msg...)for simplified panic testing in tests.
UseAssertNoPanic(t, fn, msg...)to ensure functions don't panic in tests.
UseRunConcurrentTest(t, numWorkers, workerFn)for concurrent testing with goroutines.
UseRunBenchmark(b, setupFn, execFn)for benchmark testing with setup/execution phases.
UseRunTestCases(t, []TestCase)for table-driven test runners.
Files:
spinlock_test.goslices_test.gocontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.gomaps_test.gowaitgroup_test.gotesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gozero_test.go
**/*.{md,go}
📄 CodeRabbit Inference Engine (AGENT.md)
Check spelling in both Markdown and Go source files using CSpell with configuration in
internal/build/cspell.json.
Files:
spinlock_test.goslices_test.goAGENT.mdcontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.gopanic.goTESTING.mdmaps_test.gowaitgroup_test.goREADME.mdTESTING_core.mdtesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gotesting.gozero_test.go
**/*.md
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.md: Run Markdownlint on Markdown files with configuration ininternal/build/markdownlint.json.
Enforce 80-character line limits and strict formatting rules in Markdown files.
Allow only a selective HTML allowlist (comments, br, kbd, etc.) in Markdown files.
Run LanguageTool grammar and style checking on Markdown files using British English configuration ininternal/build/languagetool.cfg.
Markdown files must comply with LanguageTool (grammar), CSpell (spelling), and Markdownlint (formatting) standards.
End all bullet points in Markdown files with periods for consistency.
Capitalize proper nouns correctly (JavaScript, TypeScript, Markdown) in Markdown files.
Use consistent punctuation in examples and lists in Markdown files.
Files:
AGENT.mdTESTING.mdREADME.mdTESTING_core.md
🧠 Learnings (37)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
📚 Learning: add technical terms to `internal/build/cspell.json` for spell checking....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Add technical terms to `internal/build/cspell.json` for spell checking.
Applied to files:
.vscode/settings.jsoninternal/build/cspell.json.vscode/cspell.json
📚 Learning: applies to **/*.{md,go} : check spelling in both markdown and go source files using cspell with conf...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.{md,go} : Check spelling in both Markdown and Go source files using CSpell with configuration in `internal/build/cspell.json`.
Applied to files:
.vscode/settings.jsoninternal/build/cspell.json.vscode/cspell.json
📚 Learning: extensive use of go 1.23+ generics for type-safe utilities....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Applied to files:
internal/build/cspell.jsonAGENT.mdpanic.goREADME.mdTESTING_core.mdtesting.gozero_test.go
📚 Learning: use only the go standard library and minimal golang.org/x packages (zero dependencies)....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Use only the Go standard library and minimal golang.org/x packages (zero dependencies).
Applied to files:
internal/build/cspell.jsonAGENT.md
📚 Learning: applies to **/*.go : cognitive complexity: 7....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cognitive complexity: 7.
Applied to files:
internal/build/cspell.jsonslices_test.gocontext_test.gowaitgroup_test.goREADME.mdpanicerror_test.gopanic_test.gotesting.gozero_test.go
📚 Learning: applies to **/*.go : max arguments: 5....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Max arguments: 5.
Applied to files:
internal/build/cspell.json
📚 Learning: applies to **/*.go : cyclomatic complexity: 10....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cyclomatic complexity: 10.
Applied to files:
internal/build/cspell.jsonTESTING.mdmaps_test.gowaitgroup_test.gopanicerror_test.goerrgroup_test.go
📚 Learning: applies to **/*.md : run markdownlint on markdown files with configuration in `internal/build/markdo...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.md : Run Markdownlint on Markdown files with configuration in `internal/build/markdownlint.json`.
Applied to files:
.vscode/cspell.json
📚 Learning: applies to **/*.md : markdown files must comply with languagetool (grammar), cspell (spelling), and ...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.md : Markdown files must comply with LanguageTool (grammar), CSpell (spelling), and Markdownlint (formatting) standards.
Applied to files:
.vscode/cspell.json
📚 Learning: applies to **/*.md : run languagetool grammar and style checking on markdown files using british eng...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.md : Run LanguageTool grammar and style checking on Markdown files using British English configuration in `internal/build/languagetool.cfg`.
Applied to files:
.vscode/cspell.json
📚 Learning: applies to **/*_test.go : use `assertsliceequal[t](t, expected, actual, msg...)` for slice compariso...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Applied to files:
spinlock_test.goslices_test.goAGENT.mdcontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.goTESTING.mdmaps_test.gowaitgroup_test.goREADME.mdTESTING_core.mdtesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gotesting.gozero_test.go
📚 Learning: applies to **/*_test.go : use `assertequal[t](t, expected, actual, msg...)` for generic value compar...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Applied to files:
spinlock_test.goslices_test.goAGENT.mdcontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.gopanic.goTESTING.mdmaps_test.gowaitgroup_test.goREADME.mdTESTING_core.mdtesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gotesting.gozero_test.go
📚 Learning: applies to **/*_test.go : use `assertpanic(t, fn, expectedpanic, msg...)` for simplified panic testi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Applied to files:
spinlock_test.goslices_test.goAGENT.mdcontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.gopanic.goTESTING.mdmaps_test.gowaitgroup_test.goREADME.mdTESTING_core.mdtesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gotesting.gozero_test.go
📚 Learning: applies to **/*_test.go : use `assertnopanic(t, fn, msg...)` to ensure functions don't panic in test...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Applied to files:
spinlock_test.goslices_test.goAGENT.mdcontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.gopanic.goTESTING.mdmaps_test.gowaitgroup_test.goREADME.mdTESTING_core.mdtesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gotesting.gozero_test.go
📚 Learning: in the darvaza.org/core module, the spinlock type is being deprecated in favor of darvaza.org/x/sync...
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.
Applied to files:
spinlock_test.goAGENT.mdTESTING_core.md
📚 Learning: applies to **/*_test.go : use `assertbool(t, actual, expected, msg...)` for boolean assertions in te...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Applied to files:
spinlock_test.goslices_test.goAGENT.mdcontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.goTESTING.mdmaps_test.gowaitgroup_test.goREADME.mdTESTING_core.mdtesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gotesting.gozero_test.go
📚 Learning: applies to **/*_test.go : use `asserterror(t, err, expecterror, msg...)` for standardized error expe...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Applied to files:
spinlock_test.goslices_test.goAGENT.mdcontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.gopanic.goTESTING.mdmaps_test.gowaitgroup_test.goREADME.mdTESTING_core.mdtesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gotesting.gozero_test.go
📚 Learning: applies to **/*_test.go : use test helper functions defined in `testutils_test.go` to reduce boilerp...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Applied to files:
spinlock_test.goslices_test.goAGENT.mdcontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.goTESTING.mdmaps_test.gowaitgroup_test.goREADME.mdTESTING_core.mdtesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gotesting.gozero_test.go
📚 Learning: applies to **/*_test.go : use `runtestcases(t, []testcase)` for table-driven test runners....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Applied to files:
spinlock_test.goslices_test.goAGENT.mdcontext_test.gostack_test.golists_test.goaddrs_test.goas_test.goerrors_test.goTESTING.mdmaps_test.gowaitgroup_test.goREADME.mdTESTING_core.mdtesting_test.gopanicerror_test.goerrgroup_test.gopanic_test.gotesting.gozero_test.go
📚 Learning: applies to **/*_test.go : use `runconcurrenttest(t, numworkers, workerfn)` for concurrent testing wi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
Applied to files:
spinlock_test.gocontext_test.goaddrs_test.goerrors_test.gomaps_test.gowaitgroup_test.goREADME.mdtesting_test.goerrgroup_test.gotesting.go
📚 Learning: in go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as ...
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.
Applied to files:
spinlock_test.golists_test.goerrors_test.gopanic.goREADME.mdzero_test.go
📚 Learning: in `list.go`, the `list[t]` methods `len` and `foreach` handle a nil receiver gracefully....
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.
Applied to files:
spinlock_test.goslices_test.golists_test.gomaps_test.goREADME.mdzero_test.go
📚 Learning: `errnilreceiver`, defined in `errors.go`, is intended for use by other packages even if it's not use...
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.
Applied to files:
spinlock_test.goerrors_test.gopanic.goREADME.mdpanic_test.gozero_test.go
📚 Learning: applies to **/*_test.go : use `runbenchmark(b, setupfn, execfn)` for benchmark testing with setup/ex...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunBenchmark(b, setupFn, execFn)` for benchmark testing with setup/execution phases.
Applied to files:
spinlock_test.goslices_test.gomaps_test.gotesting_test.goerrgroup_test.gotesting.go
📚 Learning: helper functions like `s[t]()` create test slices....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Helper functions like `S[T]()` create test slices.
Applied to files:
slices_test.goAGENT.mdas_test.gomaps_test.gozero_test.go
📚 Learning: in the go `core` package's `list.go` file, the method `unsafeforeachelement` in `list[t]` does not n...
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.
Applied to files:
slices_test.golists_test.gopanic.gomaps_test.gozero_test.go
📚 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-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
AGENT.mdTESTING.mdREADME.md
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
AGENT.mdREADME.md
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `README.md` to reflect significant changes in functionality or API.
Applied to files:
AGENT.mdTESTING.mdREADME.mdTESTING_core.md
📚 Learning: applies to **/*.go : everything is in the `core` package, no subpackages....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: Applies to **/*.go : Everything is in the `core` package, no subpackages.
Applied to files:
AGENT.mdpanic.goTESTING_core.md
📚 Learning: everything is in the `core` package, no subpackages....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Everything is in the `core` package, no subpackages.
Applied to files:
AGENT.md
📚 Learning: in the darvaza-proxy/core monorepo coverage system, each .prof coverage file is generated from a dif...
Learnt from: amery
PR: darvaza-proxy/core#113
File: internal/build/make_coverage.sh:90-93
Timestamp: 2025-07-14T17:26:02.593Z
Learning: In the darvaza-proxy/core monorepo coverage system, each .prof coverage file is generated from a different Go module, so simple concatenation of coverage files is appropriate and won't cause duplicate package lines since each module covers its own distinct set of packages.
Applied to files:
AGENT.md
📚 Learning: applies to **/*.go : field alignment optimization for struct definitions using the `fieldalignment` ...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Field alignment optimization for struct definitions using the `fieldalignment` tool.
Applied to files:
stack_test.go
📚 Learning: always run `make tidy` first before committing: fix all issues (go formatting, whitespace, cspell, m...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: ALWAYS run `make tidy` first before committing: fix all issues (Go formatting, whitespace, CSpell, markdownlint, shellcheck).
Applied to files:
TESTING.mdREADME.md
📚 Learning: when suggesting refactoring of build scripts, consider the possibility of nested `go.mod` files with...
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.
Applied to files:
waitgroup_test.gopanicerror_test.goerrgroup_test.go
📚 Learning: review documentation changes for missing articles, punctuation, and compound modifier hyphenation....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Review documentation changes for missing articles, punctuation, and compound modifier hyphenation.
Applied to files:
README.md
🧬 Code Graph Analysis (14)
spinlock_test.go (1)
testing.go (5)
AssertEqual(135-144)AssertNoError(206-209)AssertPanic(220-237)AssertNoPanic(248-261)T(20-24)
context_test.go (2)
testing.go (3)
AssertEqual(135-144)AssertTrue(273-276)AssertFalse(288-291)constraints.go (1)
String(34-36)
stack_test.go (2)
testing.go (1)
AssertEqual(135-144)stack.go (2)
Frame(35-46)Stack(242-242)
lists_test.go (2)
testing.go (4)
AssertEqual(135-144)AssertFalse(288-291)AssertTrue(273-276)T(20-24)lists.go (1)
ListContainsFn(16-26)
addrs_test.go (2)
testing.go (1)
T(20-24)addrs.go (2)
GetStringIPAddresses(10-15)ParseAddr(140-154)
as_test.go (2)
testing.go (2)
T(20-24)S(97-102)as.go (1)
As(4-7)
errors_test.go (2)
testing.go (3)
AssertEqual(135-144)AssertTrue(273-276)AssertFalse(288-291)errors.go (4)
Unwrappable(33-36)Unwrap(181-206)IsTemporary(341-344)IsTimeout(396-399)
maps_test.go (3)
testing.go (7)
AssertEqual(135-144)T(20-24)AssertTrue(273-276)AssertSliceEqual(155-164)AssertNil(340-349)S(97-102)AssertFalse(288-291)slices.go (1)
SliceContains(33-37)maps.go (10)
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)
waitgroup_test.go (2)
testing.go (4)
T(20-24)AssertError(193-196)AssertEqual(135-144)AssertNoError(206-209)sync.go (1)
WaitGroup(42-47)
testing_test.go (2)
testing.go (20)
T(20-24)S(97-102)AssertSliceEqual(155-164)MockT(28-35)AssertEqual(135-144)AssertTrue(273-276)AssertFalse(288-291)AssertContains(174-183)AssertError(193-196)AssertNoError(206-209)AssertNil(340-349)AssertNotNil(359-368)AssertErrorIs(302-311)AssertTypeIs(321-330)AssertPanic(220-237)AssertNoPanic(248-261)RunConcurrentTest(380-386)TestCase(106-109)RunTestCases(117-124)RunBenchmark(398-405)compounderror.go (1)
Errors(10-13)
errgroup_test.go (2)
sync.go (1)
ErrGroup(128-135)testing.go (3)
T(20-24)AssertError(193-196)AssertTrue(273-276)
panic_test.go (3)
panic.go (4)
Recovered(8-11)AsRecovered(15-28)Must(94-99)Maybe(115-117)testing.go (8)
T(20-24)AssertEqual(135-144)AssertError(193-196)AssertNoError(206-209)AssertSliceEqual(155-164)S(97-102)AssertTrue(273-276)AssertTypeIs(321-330)panicerror.go (1)
PanicError(16-19)
testing.go (3)
compounderror.go (1)
Errors(10-13)zero.go (1)
IsNil(132-145)sync.go (1)
WaitGroup(42-47)
zero_test.go (2)
testing.go (5)
T(20-24)AssertEqual(135-144)AssertNil(340-349)S(97-102)AssertSliceEqual(155-164)zero.go (3)
Zero(23-26)IsZero(67-85)IsNil(132-145)
🪛 LanguageTool
TESTING.md
[grammar] ~440-~440: Consider using “to” with “prefer”.
Context: ...t.Helper() in all helper functions. - Prefer table-driven tests over individual test functions. - Keep setup and clean-...
(PREFER_OVER_TO)
README.md
[style] ~213-~213: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... keys in the map. * SortedKeys[K,T]() returns a sorted slice of the keys. * `SortedVa...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~214-~214: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ce of the keys. * SortedValues[K,T]() returns values sorted by key. * `SortedValuesCo...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~215-~215: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ted by key. * SortedValuesCond[K,T]() returns filtered values sorted by key. * `Sorte...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🔇 Additional comments (49)
testing.go (7)
12-24: LGTM! Well-designed testing interface.The
Tinterface provides a clean abstraction for testing functionality, and the compile-time verification ensures proper implementation.
26-83: LGTM! Comprehensive mock implementation.The
MockTimplementation provides excellent testing capabilities with error/log collection and inspection methods.
85-102: LGTM! Elegant slice creation helper.The
Sfunction provides a concise way to create slices in tests, with proper handling of edge cases and excellent documentation.
104-124: LGTM! Clean test case abstraction.The
TestCaseinterface andRunTestCasesfunction provide an excellent pattern for structured, table-driven tests.
126-368: LGTM! Comprehensive assertion library.Excellent set of generic assertion functions with consistent patterns, proper error handling, and clear documentation. The use of helper functions for logging ensures uniform output format.
370-405: LGTM! Well-designed concurrency and benchmarking utilities.The concurrent test runner properly manages goroutines and error collection, while the benchmark helper follows standard Go patterns.
407-465: LGTM! Clean internal helper implementation.The message formatting helpers provide consistent output handling with proper support for prefix formatting. The worker management functions are well-structured with proper synchronisation.
spinlock_test.go (1)
41-41: LGTM! Improved assertion messages.The simplified messages are more concise while maintaining clarity, following best practices for test output.
Also applies to: 96-96, 104-104, 151-153, 167-167, 173-173, 179-179, 205-205, 208-208
addrs_test.go (1)
291-291: LGTM! Good test refactoring.Extracting the test logic into a named helper function improves code organisation and follows Go testing best practices.
Also applies to: 326-346
stack_test.go (2)
73-73: LGTM! More precise linter directive.Narrowing the cognitive complexity disable to just the next line is better practice than disabling for the entire function.
171-171: LGTM! Consistent message simplification.The assertion messages are now more concise while maintaining clarity, consistent with the testing improvements across the codebase.
Also applies to: 212-212, 216-216, 301-301, 305-305, 356-356, 363-363, 439-439, 498-498, 505-505, 518-518
panic.go (1)
83-117: LGTM! Excellent error handling utilities.The
MustandMaybefunctions provide clean, idiomatic Go patterns for error handling. The documentation with practical examples is particularly helpful. The use ofNewPanicWrapwith proper stack depth ensures useful panic messages.context_test.go (4)
14-35: LGTM! Excellent adoption of standardised testing assertions.The migration from manual assertions to
AssertEqual,AssertTrue, andAssertFalseimproves test readability and consistency. The assertion messages are concise and meaningful, following the established testing patterns.
54-95: LGTM! Consistent use of assertion helpers.The replacement of manual boolean checks with
AssertTrueand error comparisons withAssertEqualmaintains test functionality while improving consistency with the project's testing standards.
149-197: LGTM! Consistent assertion pattern maintained.The timeout cause tests follow the same pattern as the regular timeout tests, using appropriate assertion helpers while preserving the test logic for both error checking and cause validation.
226-227: LGTM! Appropriate use of AssertEqual for tuple return values.Using
AssertEqualfor both the value and boolean result from theGetmethod is the correct approach, maintaining clear test assertions while following the established patterns.lists_test.go (5)
120-143: LGTM! Appropriate boolean assertion usage.The use of
AssertEqualfor general boolean comparisons andAssertFalsefor specific false expectations improves test clarity while maintaining the original test logic.
166-185: LGTM! Consistent use of AssertEqual for copy verification.The assertions properly verify list length, element values, and independence after copying operations. The combination of assertion helpers with manual error reporting for the independence test is appropriate.
227-244: LGTM! Correct boolean assertion usage for function tests.The use of
AssertTruefor successful matches andAssertFalsefor edge cases (nil list, nil function) correctly reflects the expected behaviour ofListContainsFn.
262-308: LGTM! Comprehensive use of AssertEqual with helpful formatting.The consistent use of
AssertEqualfor length verification and element comparison, combined with indexed formatting in assertion messages (value[%d]), provides excellent debugging information while maintaining test clarity.
323-402: LGTM! Well-structured helper function assertions.The helper functions properly use assertion helpers while maintaining complex test logic for early return scenarios. The mix of
AssertEqualandAssertFalseappropriately reflects the different types of checks being performed.slices_test.go (10)
18-18: LGTM! Proper use of AssertSliceEqual with contextual information.Using
AssertSliceEqualfor slice comparisons with the input included in the assertion message provides excellent debugging context while following the established testing patterns.
75-91: LGTM! Consistent slice assertion usage across multiple operations.The systematic use of
AssertSliceEqualfor all unique-related operations (SliceUnique,SliceUniqueFn,SliceUniquify,SliceUniquifyFn) with clear, descriptive assertion messages maintains excellent test clarity.
122-147: LGTM! Consistent slice difference testing with helpful context.Using
AssertSliceEqualfor bothSliceMinusandSliceMinusFnoperations with input parameters included in assertion messages provides excellent debugging information while maintaining consistency.
157-170: LGTM! Improved field naming and consistent assertions.The field name change to
wantOkfollows Go naming conventions, and the use ofAssertEqualwith indexed formatting provides clear, consistent test assertions for random slice selection.
188-188: LGTM! Appropriate assertion for boolean result.Using
AssertEqualfor the boolean result ofSliceContainsmaintains consistency with the established testing patterns while preserving test functionality.
221-221: LGTM! Appropriate slice assertion for mapping operations.Using
AssertSliceEqualforSliceMapresults follows the established pattern and provides clear test verification for transformation operations.
273-277: LGTM! Comprehensive verification of non-mutating operation.Using
AssertSliceEqualto verify both the reversed result and that the original slice remains unchanged demonstrates proper testing of non-mutating operations with clear, descriptive assertion messages.
307-307: LGTM! Consistent assertion for functional slice operations.Using
AssertSliceEqualforSliceReversedFnmaintains consistency with other slice operation tests while clearly identifying the functional variant being tested.
343-384: LGTM! Comprehensive sorting test coverage with consistent assertions.Using
AssertSliceEqualforSliceSortFntesting, including edge cases like nil function handling, demonstrates thorough test coverage with consistent assertion patterns.
401-401: LGTM! Appropriate assertion for generic ordered sorting.Using
AssertSliceEqualforSliceSortOrderedmaintains consistency while testing the generic ordered type sorting functionality across multiple data types.as_test.go (2)
9-82: LGTM! Excellent refactoring for maintainability and readability.The introduction of the
testHelloconstant eliminates magic strings, and extracting type-specific test methods (testStringConversion,testIntConversion,testErrorConversion,testDefaultConversion) significantly improves code modularity and reduces duplication. This refactoring enhances maintainability while preserving test functionality.
225-567: LGTM! Consistent use of constant eliminates magic strings.The systematic replacement of hardcoded
"hello"with thetestHelloconstant throughout all test cases improves maintainability and ensures consistency. This follows good testing practices by centralising test data.AGENT.md (3)
7-13: LGTM! Excellent addition of cross-references.The new "Related Documentation" section provides valuable navigation aids and context, helping users understand how this agent guidance relates to the broader documentation ecosystem. The clear linking structure follows documentation best practices.
172-184: LGTM! Updated guidance reflects new testing infrastructure.The updates correctly emphasise that testing utilities are now public in
testing.gofor external use, and the references to comprehensive testing documentation (TESTING.mdandTESTING_core.md) provide users with detailed guidance. This aligns perfectly with the transformation to a public testing API.
185-210: LGTM! Valuable practical guidance with clear examples.The "Quick Development Reference" section provides an excellent practical example demonstrating proper usage of the new testing utilities (
AssertError,AssertNoError,AssertEqual) within a table-driven test structure. This concrete guidance will help developers quickly adopting the new testing patterns.README.md (1)
424-464: Wrap long Markdown lines and run markdownlint.Several lines in the new Testing Utilities section exceed the 80-character limit enforced by
internal/build/markdownlint.json. Re-flow the text or insert line breaks before pushing to avoid CI failures.errors_test.go (1)
290-295: Possible nil-receiver panic – double-check TemporaryError methods.
tempErris a typed*TemporaryErrornil.
You call:tempErr.IsTimeout() tempErr.Timeout()These will only be safe if both methods explicitly guard against a nil receiver.
Please verify the implementations; otherwise replace the calls with:AssertFalse(t, IsNil(tempErr), "nil receiver") // or similarto avoid a runtime panic on future refactors.
TESTING_core.md (1)
140-156: Potential 80-char line overflow.Lines containing
"AssertTrue(t, addr.IsValid(), \"address[%d] should be valid\", i)"and similar are >80 chars. Break them to keep markdownlint happy.testing_test.go (1)
1-481: Excellent test coverage for the new testing framework!The test file comprehensively covers all aspects of the testing utilities including MockT, assertion functions, concurrent testing, and benchmarking. The tests are well-structured with clear subtests and proper use of helper functions.
panicerror_test.go (1)
289-291: Replace t.Fatalf with AssertTypeIs.Use the type assertion helper for consistency.
- if !ok { - t.Fatalf("expected PanicError, got %T", r) - } + AssertTrue(t, ok, "PanicError type assertion")⛔ Skipped due to learnings
Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.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#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.errgroup_test.go (2)
434-474: Good refactoring of concurrency tests!The extraction of
startConcurrentWorkers,createConcurrentWorker, andvalidateConcurrencyResultimproves test readability and properly uses the new assertion helpers.
167-169: Use AssertTrue for cancellation check.- if tc.expectCancel && !eg.IsCancelled() { - t.Error("Expected group to be cancelled") - } + if tc.expectCancel { + AssertTrue(t, eg.IsCancelled(), "group cancelled") + }⛔ Skipped due to learnings
Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.zero_test.go (4)
10-88: Excellent use of generics for test case structures!The generic test case design with specialised types for slices, maps, pointers, interfaces, channels, and functions provides excellent type safety and code reuse. Each test case type has a focused test method that uses appropriate assertions.
90-298: Well-structured TestZero with comprehensive coverage!The test is excellently organised with subtests for each type, and each subtest properly covers both nil and non-nil pointer scenarios. The consistent pattern makes the tests easy to understand and maintain.
321-591: Comprehensive IsZero test coverage!Excellent coverage including:
- All primitive types (integers, floats, complex numbers, etc.)
- Edge cases (nil vs empty slices/maps)
- Complex and nested structs
- Interface scenarios
- Reflect.Value handling
The tests are well-organised and use assertion helpers consistently.
615-774: Thorough IsNil test implementation!The tests are well-organised into logical groups (basic, pointers, slices, maps, channels, functions, interfaces) with comprehensive coverage including typed nil scenarios and reflect.Value handling. Excellent test structure and consistency.
panic_test.go (2)
52-68: Good refactoring into helper methods.The decomposition of the test logic into
checkNilResult,checkRecoveredValue, andcheckErrorStringimproves readability and follows the single responsibility principle.
490-528: Excellent use of generics and type-safe testing.The generic helpers
testMustTandtestMustSliceprovide type-safe testing while the type switch intestMustWithValueensures proper dispatch. This is a clean implementation that leverages Go's type system effectively.
🔧 PR UpdateRace Condition Fixed:
DeepSource Compliance:
Clean History: Used Status: All CI checks now passing (Build ✅, Test ✅, Coverage 96.9% ✅). Ready for review. |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
README.md (1)
213-216: Address repeated sentence beginnings in map operations documentation.The static analysis tool correctly identifies that three successive sentences begin with "returns", which impacts readability.
Consider varying the sentence structure:
-* `Keys[K,T]()` returns a slice of the keys in the map. -* `SortedKeys[K,T]()` returns a sorted slice of the keys. -* `SortedValues[K,T]()` returns values sorted by key. +* `Keys[K,T]()` returns a slice of the keys in the map. +* `SortedKeys[K,T]()` provides a sorted slice of the keys. +* `SortedValues[K,T]()` retrieves values sorted by key.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (23)
AGENT.md(2 hunks)README.md(8 hunks)TESTING.md(1 hunks)TESTING_core.md(1 hunks)addrs_test.go(2 hunks)as_test.go(6 hunks)context_test.go(10 hunks)errgroup_test.go(4 hunks)errors_test.go(11 hunks)internal/build/cspell.json(1 hunks)lists_test.go(14 hunks)maps_test.go(25 hunks)panic.go(1 hunks)panic_test.go(8 hunks)panicerror_test.go(2 hunks)slices_test.go(12 hunks)spinlock_test.go(5 hunks)stack_test.go(8 hunks)testing.go(1 hunks)testing_test.go(1 hunks)testutils_test.go(0 hunks)waitgroup_test.go(4 hunks)zero_test.go(2 hunks)
💤 Files with no reviewable changes (1)
- testutils_test.go
🚧 Files skipped from review as they are similar to previous changes (17)
- internal/build/cspell.json
- stack_test.go
- errors_test.go
- spinlock_test.go
- slices_test.go
- addrs_test.go
- as_test.go
- AGENT.md
- panic.go
- lists_test.go
- maps_test.go
- waitgroup_test.go
- testing_test.go
- context_test.go
- panicerror_test.go
- testing.go
- errgroup_test.go
🧰 Additional context used
📓 Path-based instructions (5)
**/*
📄 CodeRabbit Inference Engine (AGENT.md)
**/*: Remove trailing whitespace from all text files.
Ensure files end with a newline.
Files:
TESTING_core.mdzero_test.gopanic_test.goREADME.mdTESTING.md
**/*.md
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.md: Run Markdownlint on Markdown files with configuration ininternal/build/markdownlint.json.
Enforce 80-character line limits and strict formatting rules in Markdown files.
Allow only a selective HTML allowlist (comments, br, kbd, etc.) in Markdown files.
Run LanguageTool grammar and style checking on Markdown files using British English configuration ininternal/build/languagetool.cfg.
Markdown files must comply with LanguageTool (grammar), CSpell (spelling), and Markdownlint (formatting) standards.
End all bullet points in Markdown files with periods for consistency.
Capitalize proper nouns correctly (JavaScript, TypeScript, Markdown) in Markdown files.
Use consistent punctuation in examples and lists in Markdown files.
Files:
TESTING_core.mdREADME.mdTESTING.md
**/*.{md,go}
📄 CodeRabbit Inference Engine (AGENT.md)
Check spelling in both Markdown and Go source files using CSpell with configuration in
internal/build/cspell.json.
Files:
TESTING_core.mdzero_test.gopanic_test.goREADME.mdTESTING.md
**/*.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.go: Enforce strict linting rules via revive with configuration ininternal/build/revive.toml.
Max function length: 40 lines.
Max function results: 3.
Max arguments: 5.
Cognitive complexity: 7.
Cyclomatic complexity: 10.
Field alignment optimization for struct definitions using thefieldalignmenttool.
Files:
zero_test.gopanic_test.go
**/*_test.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*_test.go: Use test helper functions defined intestutils_test.goto reduce boilerplate and improve test consistency.
UseAssertEqual[T](t, expected, actual, msg...)for generic value comparison in tests.
UseAssertSliceEqual[T](t, expected, actual, msg...)for slice comparison in tests.
UseAssertError(t, err, expectError, msg...)for standardized error expectation checking in tests.
UseAssertBool(t, actual, expected, msg...)for boolean assertions in tests.
UseAssertPanic(t, fn, expectedPanic, msg...)for simplified panic testing in tests.
UseAssertNoPanic(t, fn, msg...)to ensure functions don't panic in tests.
UseRunConcurrentTest(t, numWorkers, workerFn)for concurrent testing with goroutines.
UseRunBenchmark(b, setupFn, execFn)for benchmark testing with setup/execution phases.
UseRunTestCases(t, []TestCase)for table-driven test runners.
Files:
zero_test.gopanic_test.go
🧠 Learnings (26)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `README.md` to reflect significant changes in functionality or API.
Applied to files:
TESTING_core.mdREADME.mdTESTING.md
📚 Learning: applies to **/*.go : everything is in the `core` package, no subpackages....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: Applies to **/*.go : Everything is in the `core` package, no subpackages.
Applied to files:
TESTING_core.md
📚 Learning: in the darvaza.org/core module, the spinlock type is being deprecated in favor of darvaza.org/x/sync...
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.
Applied to files:
TESTING_core.md
📚 Learning: applies to **/*_test.go : use `assertequal[t](t, expected, actual, msg...)` for generic value compar...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Applied to files:
TESTING_core.mdzero_test.gopanic_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use test helper functions defined in `testutils_test.go` to reduce boilerp...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Applied to files:
TESTING_core.mdzero_test.gopanic_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `assertsliceequal[t](t, expected, actual, msg...)` for slice compariso...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Applied to files:
TESTING_core.mdzero_test.gopanic_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `asserterror(t, err, expecterror, msg...)` for standardized error expe...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Applied to files:
TESTING_core.mdzero_test.gopanic_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `assertbool(t, actual, expected, msg...)` for boolean assertions in te...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Applied to files:
TESTING_core.mdzero_test.gopanic_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `assertnopanic(t, fn, msg...)` to ensure functions don't panic in test...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Applied to files:
TESTING_core.mdzero_test.gopanic_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `assertpanic(t, fn, expectedpanic, msg...)` for simplified panic testi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Applied to files:
TESTING_core.mdzero_test.gopanic_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `runtestcases(t, []testcase)` for table-driven test runners....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Applied to files:
TESTING_core.mdzero_test.gopanic_test.goREADME.mdTESTING.md
📚 Learning: extensive use of go 1.23+ generics for type-safe utilities....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Applied to files:
TESTING_core.mdzero_test.goREADME.md
📚 Learning: applies to **/*.go : cognitive complexity: 7....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cognitive complexity: 7.
Applied to files:
zero_test.gopanic_test.goREADME.md
📚 Learning: helper functions like `s[t]()` create test slices....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Helper functions like `S[T]()` create test slices.
Applied to files:
zero_test.go
📚 Learning: in `list.go`, the `list[t]` methods `len` and `foreach` handle a nil receiver gracefully....
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.
Applied to files:
zero_test.goREADME.md
📚 Learning: in go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as ...
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.
Applied to files:
zero_test.goREADME.md
📚 Learning: in the go `core` package's `list.go` file, the method `unsafeforeachelement` in `list[t]` does not n...
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.
Applied to files:
zero_test.go
📚 Learning: `errnilreceiver`, defined in `errors.go`, is intended for use by other packages even if it's not use...
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.
Applied to files:
panic_test.goREADME.md
📚 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-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
README.mdTESTING.md
📚 Learning: review documentation changes for missing articles, punctuation, and compound modifier hyphenation....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Review documentation changes for missing articles, punctuation, and compound modifier hyphenation.
Applied to files:
README.md
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
README.md
📚 Learning: integrate whitespace and eof fixes with `make fmt` for non-go files....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Integrate whitespace and EOF fixes with `make fmt` for non-Go files.
Applied to files:
README.md
📚 Learning: always run `make tidy` first before committing: fix all issues (go formatting, whitespace, cspell, m...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: ALWAYS run `make tidy` first before committing: fix all issues (Go formatting, whitespace, CSpell, markdownlint, shellcheck).
Applied to files:
README.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `runconcurrenttest(t, numworkers, workerfn)` for concurrent testing wi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
Applied to files:
README.md
📚 Learning: applies to **/*.go : cyclomatic complexity: 10....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cyclomatic complexity: 10.
Applied to files:
TESTING.md
🧬 Code Graph Analysis (2)
zero_test.go (2)
testing.go (5)
T(20-24)AssertEqual(135-144)AssertNil(340-349)S(97-102)AssertSliceEqual(155-164)zero.go (3)
Zero(23-26)IsZero(67-85)IsNil(132-145)
panic_test.go (3)
panic.go (4)
Recovered(8-11)AsRecovered(15-28)Must(94-99)Maybe(115-117)testing.go (8)
T(20-24)AssertEqual(135-144)AssertError(193-196)AssertNoError(206-209)AssertSliceEqual(155-164)S(97-102)AssertTrue(273-276)AssertTypeIs(321-330)panicerror.go (1)
PanicError(16-19)
🪛 LanguageTool
README.md
[style] ~213-~213: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... keys in the map. * SortedKeys[K,T]() returns a sorted slice of the keys. * `SortedVa...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~214-~214: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ce of the keys. * SortedValues[K,T]() returns values sorted by key. * `SortedValuesCo...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~215-~215: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ted by key. * SortedValuesCond[K,T]() returns filtered values sorted by key. * `Sorte...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
TESTING.md
[grammar] ~440-~440: Consider using “to” with “prefer”.
Context: ...t.Helper() in all helper functions. - Prefer table-driven tests over individual test functions. - Keep setup and clean-...
(PREFER_OVER_TO)
🔇 Additional comments (20)
README.md (1)
293-479: Excellent documentation of new Must/Maybe utilities and testing infrastructure.The new sections comprehensively document the Must/Maybe error handling utilities and the public testing API. The code examples are clear and demonstrate practical usage patterns. The integration with the existing documentation structure is well done.
TESTING_core.md (1)
1-424: Comprehensive and well-structured testing documentation.This document provides excellent guidance for testing the core package itself. Key strengths include:
- Clear examples of self-testing patterns using MockT
- Comprehensive coverage of generic function testing
- Proper handling of circular dependency issues
- Zero dependency requirements clearly explained
- Performance and edge case testing patterns included
The examples are practical and demonstrate the testing utilities effectively. The document serves as an excellent complement to the main testing guidelines.
TESTING.md (1)
1-529: Excellent comprehensive testing guidelines document.This document establishes clear, consistent testing standards across all darvaza.org projects. Key strengths include:
- Well-defined core testing principles with specific complexity limits
- Clear guidance on assertion function usage with helpful prefix examples
- Comprehensive test structure patterns with named types and test methods
- Practical complexity management strategies
- Clear forbidden/allowed patterns section
The document will significantly improve testing consistency and quality across the ecosystem.
Note: The static analysis hint about "prefer over to" on line 440 is a false positive - "prefer X over Y" is the correct and natural phrasing in this context.
panic_test.go (3)
52-113: Excellent refactoring of test method into focused helper functions.The decomposition of the
asRecoveredTestCase.testmethod into smaller, focused helper methods (checkNilResult,checkRecoveredValue,checkStringValue,checkErrorValue,checkErrorString) significantly improves maintainability and readability. Each helper has a single responsibility and proper use oft.Helper().
177-209: Good modularisation of error and panic checking logic.The extraction of
checkErrorandcheckPanichelper methods from the main test method improves clarity and follows the complexity management guidelines. The consistent use ofAssertErrorandAssertNoErroraligns with the new testing standards.
446-662: Comprehensive test coverage for new Must/Maybe utilities.The new test coverage for
MustandMaybefunctions is excellent:
- Must testing: Properly tests both success and panic scenarios with comprehensive type coverage
- Generic test helpers: The
testMustTandtestMustSlicehelpers provide reusable testing patterns- Panic verification: Correctly verifies that
Mustpanics contain the original error and stack traces- Maybe testing: Comprehensive coverage across different types with and without errors
- Type safety: Good use of type switches to handle different value types
The test structure follows the established patterns from the testing guidelines with named test case types and proper field alignment.
zero_test.go (14)
10-88: Excellent use of generic test case structures following new testing patterns.The generic test case types (
zeroTestCase[T],zeroSliceTestCase, etc.) with their associatedtestmethods are well-designed and follow the new testing guidelines. The factory function pattern allows for flexible test data creation whilst maintaining type safety.
90-102: Well-structured test organisation using subtests.The main
TestZerofunction properly organises different test categories using subtests, which improves test readability and allows for targeted test execution.
104-298: Proper implementation of table-driven tests with new assertion helpers.All test functions correctly use the new
AssertEqualandAssertNilhelpers from the testing utilities. The consistent pattern of creating test cases and iterating through them with subtests aligns perfectly with the new testing guidelines.
306-311: Consistent use of testing helpers in test methods.The
isZeroTestCase.testmethod properly callst.Helper()and uses the newAssertEqualhelper, maintaining consistency with the established testing patterns.
321-368: Comprehensive coverage of basic types with proper test organisation.The
TestIsZerofunction includes extensive coverage of all Go basic types (int variants, uint variants, float variants, complex types, rune, byte, uintptr). The test cases are well-organised and use the factory function pattern consistently.
370-399: Thorough interface testing with edge cases.The
TestIsZeroInterfacefunction covers important edge cases for interface types, including nil interfaces, interfaces containing nil pointers, and interfaces containing various value types. The distinction between empty slices and nil slices is correctly tested.
401-427: Comprehensive edge case coverage.The
TestIsZeroEdgeCasesfunction covers important distinctions between nil and empty values for slices, maps, channels, and functions, as well as array testing. This demonstrates thorough understanding of Go's zero value semantics.
429-482: Practical edge case testing with real-world scenarios.The
TestZeroEdgeCasesfunction tests theZerofunction with practical scenarios, including initialisation and usage patterns. The tests demonstrate both the zero-value behaviour and subsequent usage, which is valuable for documentation purposes.
484-499: Proper testing of reflect.Value edge cases.The
TestIsZeroReflectValuefunction correctly tests the special handling ofreflect.Valuetypes, including invalid (zero) reflect values and valid reflect values containing different types of data.
501-537: Thorough testing of complex struct scenarios.The
complexStructtype andTestIsZeroComplexStructfunction provide comprehensive testing of struct zero-value behaviour with various field types. The distinction between nil slices/maps (which contribute to zero-ness) and empty slices/maps (which don't) is correctly tested.
539-562: Comprehensive pointer testing scenarios.The
TestIsZeroPointersfunction covers various pointer scenarios including nil pointers, pointers to zero values, pointers to non-zero values, and pointers to nil pointers. This thorough coverage ensures theIsZerofunction handles pointer semantics correctly.
564-591: Proper nested struct testing.The nested struct testing with
outerStructandinnerStructcorrectly validates that zero-value determination works properly with nested structures, including the distinction between nil pointers to structs and pointers to zero-value structs.
593-623: Well-organised IsNil test structure.The
TestIsNilfunction uses a clean subtest organisation that mirrors the structure used forTestZero, providing consistent test organisation throughout the file.
625-774: Comprehensive IsNil testing with proper categorisation.The various
testIsNil*functions provide thorough coverage of nil semantics across different Go types. The tests correctly distinguish between nil values and non-nil but empty values, and include important edge cases like typed nil interfaces and closed channels.
🔧 PR Update: Addressed CodeRabbit FeedbackFixed actionable issues:
Impact: All tests pass, improved code consistency, reduced duplication, maintained backward compatibility. |
|
Persistent review updated to latest commit a79bb52 |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
README.md (1)
213-216: Consider varying sentence structure for better readability.Whilst the current format is clear, you could improve readability by varying the sentence beginnings:
-* `Keys[K,T]()` returns a slice of the keys in the map. -* `SortedKeys[K,T]()` returns a sorted slice of the keys. -* `SortedValues[K,T]()` returns values sorted by key. -* `SortedValuesCond[K,T]()` returns filtered values sorted by key. +* `Keys[K,T]()` returns a slice of the keys in the map. +* `SortedKeys[K,T]()` provides a sorted slice of the keys. +* `SortedValues[K,T]()` retrieves values sorted by key. +* `SortedValuesCond[K,T]()` filters and returns values sorted by key.TESTING.md (1)
440-440: Minor grammar correction needed.-- Prefer table-driven tests over individual test functions. +- Prefer table-driven tests to individual test functions.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (23)
AGENT.md(2 hunks)README.md(8 hunks)TESTING.md(1 hunks)TESTING_core.md(1 hunks)addrs_test.go(2 hunks)as_test.go(6 hunks)context_test.go(10 hunks)errgroup_test.go(4 hunks)errors_test.go(11 hunks)internal/build/cspell.json(4 hunks)lists_test.go(14 hunks)maps_test.go(25 hunks)panic.go(1 hunks)panic_test.go(8 hunks)panicerror_test.go(2 hunks)slices_test.go(12 hunks)spinlock_test.go(5 hunks)stack_test.go(8 hunks)testing.go(1 hunks)testing_test.go(1 hunks)testutils_test.go(0 hunks)waitgroup_test.go(6 hunks)zero_test.go(2 hunks)
💤 Files with no reviewable changes (1)
- testutils_test.go
✅ Files skipped from review due to trivial changes (1)
- stack_test.go
🚧 Files skipped from review as they are similar to previous changes (15)
- spinlock_test.go
- addrs_test.go
- panic.go
- slices_test.go
- errors_test.go
- lists_test.go
- internal/build/cspell.json
- AGENT.md
- maps_test.go
- as_test.go
- testing_test.go
- panicerror_test.go
- context_test.go
- waitgroup_test.go
- errgroup_test.go
🧰 Additional context used
📓 Path-based instructions (5)
**/*
📄 CodeRabbit Inference Engine (AGENT.md)
**/*: Remove trailing whitespace from all text files.
Ensure files end with a newline.
Files:
TESTING_core.mdTESTING.mdtesting.gopanic_test.gozero_test.goREADME.md
**/*.md
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.md: Run Markdownlint on Markdown files with configuration ininternal/build/markdownlint.json.
Enforce 80-character line limits and strict formatting rules in Markdown files.
Allow only a selective HTML allowlist (comments, br, kbd, etc.) in Markdown files.
Run LanguageTool grammar and style checking on Markdown files using British English configuration ininternal/build/languagetool.cfg.
Markdown files must comply with LanguageTool (grammar), CSpell (spelling), and Markdownlint (formatting) standards.
End all bullet points in Markdown files with periods for consistency.
Capitalize proper nouns correctly (JavaScript, TypeScript, Markdown) in Markdown files.
Use consistent punctuation in examples and lists in Markdown files.
Files:
TESTING_core.mdTESTING.mdREADME.md
**/*.{md,go}
📄 CodeRabbit Inference Engine (AGENT.md)
Check spelling in both Markdown and Go source files using CSpell with configuration in
internal/build/cspell.json.
Files:
TESTING_core.mdTESTING.mdtesting.gopanic_test.gozero_test.goREADME.md
**/*.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.go: Enforce strict linting rules via revive with configuration ininternal/build/revive.toml.
Max function length: 40 lines.
Max function results: 3.
Max arguments: 5.
Cognitive complexity: 7.
Cyclomatic complexity: 10.
Field alignment optimization for struct definitions using thefieldalignmenttool.
Files:
testing.gopanic_test.gozero_test.go
**/*_test.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*_test.go: Use test helper functions defined intestutils_test.goto reduce boilerplate and improve test consistency.
UseAssertEqual[T](t, expected, actual, msg...)for generic value comparison in tests.
UseAssertSliceEqual[T](t, expected, actual, msg...)for slice comparison in tests.
UseAssertError(t, err, expectError, msg...)for standardized error expectation checking in tests.
UseAssertBool(t, actual, expected, msg...)for boolean assertions in tests.
UseAssertPanic(t, fn, expectedPanic, msg...)for simplified panic testing in tests.
UseAssertNoPanic(t, fn, msg...)to ensure functions don't panic in tests.
UseRunConcurrentTest(t, numWorkers, workerFn)for concurrent testing with goroutines.
UseRunBenchmark(b, setupFn, execFn)for benchmark testing with setup/execution phases.
UseRunTestCases(t, []TestCase)for table-driven test runners.
Files:
panic_test.gozero_test.go
🧠 Learnings (28)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `README.md` to reflect significant changes in functionality or API.
Applied to files:
TESTING_core.mdTESTING.mdREADME.md
📚 Learning: applies to **/*.go : everything is in the `core` package, no subpackages....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: Applies to **/*.go : Everything is in the `core` package, no subpackages.
Applied to files:
TESTING_core.md
📚 Learning: in the darvaza.org/core module, the spinlock type is being deprecated in favor of darvaza.org/x/sync...
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.
Applied to files:
TESTING_core.md
📚 Learning: applies to **/*_test.go : use `assertequal[t](t, expected, actual, msg...)` for generic value compar...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Applied to files:
TESTING_core.mdTESTING.mdtesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use test helper functions defined in `testutils_test.go` to reduce boilerp...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Applied to files:
TESTING_core.mdTESTING.mdtesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertsliceequal[t](t, expected, actual, msg...)` for slice compariso...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Applied to files:
TESTING_core.mdTESTING.mdtesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `asserterror(t, err, expecterror, msg...)` for standardized error expe...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Applied to files:
TESTING_core.mdTESTING.mdtesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertbool(t, actual, expected, msg...)` for boolean assertions in te...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Applied to files:
TESTING_core.mdTESTING.mdtesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertnopanic(t, fn, msg...)` to ensure functions don't panic in test...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Applied to files:
TESTING_core.mdTESTING.mdtesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertpanic(t, fn, expectedpanic, msg...)` for simplified panic testi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Applied to files:
TESTING_core.mdTESTING.mdtesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runtestcases(t, []testcase)` for table-driven test runners....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Applied to files:
TESTING_core.mdTESTING.mdtesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: extensive use of go 1.23+ generics for type-safe utilities....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Applied to files:
TESTING_core.mdtesting.gozero_test.goREADME.md
📚 Learning: applies to **/*.go : cognitive complexity: 7....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cognitive complexity: 7.
Applied to files:
TESTING.mdtesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*.go : cyclomatic complexity: 10....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cyclomatic complexity: 10.
Applied to files:
TESTING.mdpanic_test.go
📚 Learning: always run `make tidy` first before committing: fix all issues (go formatting, whitespace, cspell, m...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: ALWAYS run `make tidy` first before committing: fix all issues (Go formatting, whitespace, CSpell, markdownlint, shellcheck).
Applied to files:
TESTING.mdREADME.md
📚 Learning: applies to **/*_test.go : use `runconcurrenttest(t, numworkers, workerfn)` for concurrent testing wi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
Applied to files:
testing.goREADME.md
📚 Learning: applies to **/*_test.go : use `runbenchmark(b, setupfn, execfn)` for benchmark testing with setup/ex...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunBenchmark(b, setupFn, execFn)` for benchmark testing with setup/execution phases.
Applied to files:
testing.go
📚 Learning: when suggesting refactoring of build scripts, consider the possibility of nested `go.mod` files with...
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.
Applied to files:
panic_test.go
📚 Learning: `errnilreceiver`, defined in `errors.go`, is intended for use by other packages even if it's not use...
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.
Applied to files:
panic_test.gozero_test.goREADME.md
📚 Learning: helper functions like `s[t]()` create test slices....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Helper functions like `S[T]()` create test slices.
Applied to files:
zero_test.go
📚 Learning: in `list.go`, the `list[t]` methods `len` and `foreach` handle a nil receiver gracefully....
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.
Applied to files:
zero_test.goREADME.md
📚 Learning: in go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as ...
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.
Applied to files:
zero_test.goREADME.md
📚 Learning: in the go `core` package's `list.go` file, the method `unsafeforeachelement` in `list[t]` does not n...
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.
Applied to files:
zero_test.go
📚 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-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
README.md
📚 Learning: review documentation changes for missing articles, punctuation, and compound modifier hyphenation....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Review documentation changes for missing articles, punctuation, and compound modifier hyphenation.
Applied to files:
README.md
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
README.md
📚 Learning: integrate whitespace and eof fixes with `make fmt` for non-go files....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Integrate whitespace and EOF fixes with `make fmt` for non-Go files.
Applied to files:
README.md
🧬 Code Graph Analysis (1)
panic_test.go (3)
panic.go (4)
Recovered(8-11)AsRecovered(15-28)Must(94-99)Maybe(115-117)testing.go (8)
T(20-24)AssertEqual(135-144)AssertError(193-196)AssertNoError(206-209)AssertSliceEqual(155-164)S(97-102)AssertTrue(273-276)AssertTypeIs(321-330)panicerror.go (1)
PanicError(16-19)
🪛 LanguageTool
TESTING.md
[grammar] ~440-~440: Consider using “to” with “prefer”.
Context: ...t.Helper() in all helper functions. - Prefer table-driven tests over individual test functions. - Keep setup and clean-...
(PREFER_OVER_TO)
README.md
[style] ~213-~213: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... keys in the map. * SortedKeys[K,T]() returns a sorted slice of the keys. * `SortedVa...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~214-~214: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ce of the keys. * SortedValues[K,T]() returns values sorted by key. * `SortedValuesCo...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~215-~215: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ted by key. * SortedValuesCond[K,T]() returns filtered values sorted by key. * `Sorte...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🔇 Additional comments (31)
panic_test.go (4)
52-113: Excellent refactoring of test methods!The extraction of helper methods (
checkNilResult,checkRecoveredValue,checkStringValue,checkErrorValue,checkErrorString) significantly improves code modularity and readability whilst maintaining low cognitive complexity.
177-209: Well-structured test helpers for Catcher.Do tests.The extraction of
checkErrorandcheckPanichelper methods improves clarity and maintains consistency with the new assertion patterns.
446-592: Comprehensive test coverage for Must utility!Excellent implementation of Must function tests:
- Well-designed test helper
testMustproperly handles panic recovery- Generic test helpers (
testMustT,testMustSlice) provide type-safe testing- Good coverage of success and panic scenarios
- Proper field alignment in test structs
594-662: Thorough test coverage for Maybe utility!The Maybe function tests properly verify that values are returned regardless of error state, with good coverage across different types.
testing.go (4)
18-83: Well-designed testing abstraction!The
Tinterface andMockTimplementation provide an excellent foundation for the testing infrastructure:
- Clean interface design with minimal surface area
- Comprehensive MockT implementation with inspection capabilities
- Proper compile-time verification
126-368: Comprehensive and well-designed assertion functions!Excellent implementation of assertion helpers:
- Consistent pattern across all assertions
- Type-safe with generics
- Success logging for debugging
- Clear parameter naming and documentation
407-441: Clean message formatting implementation!The internal message formatting helpers are well-structured with appropriate use of
revive:disablefor justified cases.
370-405: Excellent concurrent and benchmark testing utilities!Well-implemented helpers:
- Proper goroutine management with sync.WaitGroup
- Clean error collection pattern
- Correct benchmark timer management
Also applies to: 443-465
TESTING_core.md (1)
1-425: Excellent testing documentation for core package!This comprehensive guide provides:
- Clear self-testing patterns using MockT
- Thorough examples for all core utilities
- Important guidance on avoiding circular dependencies
- Performance testing considerations
- Well-structured sections with practical examples
README.md (3)
22-30: Good formatting consistency!Adding periods to all bullet points improves consistency throughout the documentation.
293-313: Well-documented Must/Maybe utilities!Clear explanation of the new error-handling utilities with practical examples showing appropriate use cases for each function.
424-464: Comprehensive testing utilities documentation!Excellent addition documenting the new public testing API with:
- Clear quick reference examples
- Feature summary
- Links to detailed documentation
TESTING.md (1)
1-530: Outstanding testing guidelines document!This comprehensive guide establishes excellent standards for testing across darvaza.org projects:
- Clear principles and patterns
- Practical examples with do's and don'ts
- Complexity management strategies
- Integration with CI/CD
- Consistent with the new testing infrastructure
zero_test.go (18)
10-20: Excellent implementation of generic test case pattern.The
zeroTestCase[T comparable]struct and itstestmethod exemplify the new testing patterns introduced in this PR. The use of generics ensures type safety whilst the standardised structure promotes consistency across test files.
22-32: Well-designed reference type test case.The
zeroRefTestCase[T any]properly handles reference types that should return nil. The use of*new(T)in the format string is a clever way to get the type name for logging.
34-47: Constructor functions enhance readability.The
newZeroTestCaseandnewZeroRefTestCaseconstructor functions improve test case creation readability and ensure consistent field initialisation.
58-107: Comprehensive test case coverage using ST utility.Excellent use of the
S[T]()utility function for creating test slices, which aligns with the new testing infrastructure. The test cases cover a wide range of types including basic types, slices, maps, pointers, interfaces, channels, and functions.
108-120: Clean test organisation with subtests.The
TestZerofunction is well-structured using subtests for different type categories. The use of anonymous functions for some cases and named functions for others provides good balance between conciseness and readability.
129-153: Proper handling of struct test cases.The
testZeroStructfunction correctly demonstrates testing with custom struct types. The inline struct definition and test case creation follow the established patterns.
161-166: Consistent assertion usage.The
isZeroTestCase.testmethod properly usesAssertEqualfrom the new testing utilities, maintaining consistency with the refactored testing approach.
176-223: Comprehensive basic type coverage.The test cases for
TestIsZeroprovide excellent coverage of all basic Go types including signed/unsigned integers, floating-point numbers, complex numbers, and special types like rune, byte, and uintptr.
225-254: Thorough interface testing.The
TestIsZeroInterfacefunction properly tests various interface scenarios including nil interfaces, interfaces containing nil pointers, and interfaces containing different value types. The distinction between empty slices and nil slices is correctly handled.
257-282: Good edge case coverage.The edge case tests properly distinguish between nil and empty collections (slices, maps), which is crucial for understanding Go's zero value semantics.
284-337: Practical usage examples in tests.The
TestZeroEdgeCasesfunction provides practical examples of how theZerofunction works with different types, including realistic usage patterns like initialising slices, maps, pointers, channels, and functions.
339-354: Proper reflect.Value handling.The test correctly handles both invalid and valid
reflect.Valueinstances, ensuring theIsZerofunction works properly with reflection scenarios.
356-392: Complex struct testing demonstrates real-world scenarios.The
complexStructtype and its associated tests provide excellent coverage of howIsZerohandles structs with various field types including maps, pointers, channels, functions, strings, slices, and basic types.
394-417: Thorough pointer semantics testing.The pointer tests correctly verify the behaviour of
IsZerowith various pointer scenarios, including nil pointers, pointers to zero values, and nested pointer relationships.
419-446: Nested struct testing ensures proper recursion.The nested struct tests verify that
IsZerocorrectly handles recursive checking of struct fields, which is important for complex data structures.
470-596: Comprehensive IsNil test suite.The
TestIsNilfunction is well-organised into subtests covering all nilable types in Go. The separation into different test functions (testIsNilBasic,testIsNilPointers, etc.) provides good modularity whilst maintaining comprehensive coverage.
598-621: Proper reflect.Value nil testing.The
TestIsNilReflectValuefunction correctly testsIsNilbehaviour withreflect.Valueinstances, including invalid values, nil pointers, non-nil pointers, and basic types.
623-643: Advanced nil semantics testing.The
TestIsNilTypedInterfacefunction tests sophisticated nil scenarios including typed nil in interfaces, collections containing nil elements, and closed channels. This demonstrates a deep understanding of Go's nil semantics.
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (2)
panic_test.go (2)
288-309: Use assertion helpers consistently throughout the test.Replace manual nil checks with standardised assertion helpers.
// Initially no panic - if recovered := catcher.Recovered(); recovered != nil { - t.Fatalf("expected nil recovered, got %v", recovered) - } + AssertNil(t, catcher.Recovered(), "initial recovered") // After panic _ = catcher.Try(func() error { panic("test panic") }) recovered := catcher.Recovered() - if recovered == nil { - t.Fatalf("expected recovered panic, got nil") - } + AssertNotNil(t, recovered, "recovered panic") // String panics get converted to errors by NewPanicError - if err, ok := recovered.Recovered().(error); ok { + err, ok := AssertTypeIs[error](t, recovered.Recovered(), "recovered type") + if ok { AssertEqual(t, "test panic", err.Error(), "error message") - } else { - t.Fatalf("expected error type for string panic, got %T", recovered.Recovered()) }
336-351: Use assertion helpers for nil checks and type assertions.Replace manual checks with standardised helpers for consistency.
recovered := catcher.Recovered() - if recovered == nil { - t.Fatalf("expected recovered panic, got nil") - } + AssertNotNil(t, recovered, "recovered panic") // Should be either "first panic" or "second panic" (converted to errors) panicValue := recovered.Recovered() - if err, ok := panicValue.(error); ok { + err, ok := AssertTypeIs[error](t, panicValue, "panic type") + if ok { errorStr := err.Error() - if errorStr != "first panic" && errorStr != "second panic" { - t.Fatalf("unexpected panic value: %v", errorStr) - } - } else { - t.Fatalf("expected error type for string panic, got %T", panicValue) + AssertTrue(t, errorStr == "first panic" || errorStr == "second panic", + "panic value", "got %q", errorStr) }
🧹 Nitpick comments (2)
README.md (1)
213-216: Consider varying sentence beginnings for better readability.The static analysis tool correctly identifies that three consecutive sentences begin with "returns". Consider rephrasing to improve flow:
-* `SortedKeys[K,T]()` returns a sorted slice of the keys. -* `SortedValues[K,T]()` returns values sorted by key. -* `SortedValuesCond[K,T]()` returns filtered values sorted by key. +* `SortedKeys[K,T]()` returns a sorted slice of the keys. +* `SortedValues[K,T]()` provides values sorted by key. +* `SortedValuesCond[K,T]()` yields filtered values sorted by key.TESTING.md (1)
487-487: Fix grammar issue with "prefer" usage.The static analysis tool correctly identifies a grammar issue. "Prefer" should be followed by "to" when comparing options.
-- Prefer table-driven tests over individual test functions. +- Prefer table-driven tests to individual test functions.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (23)
AGENT.md(2 hunks)README.md(8 hunks)TESTING.md(1 hunks)TESTING_core.md(1 hunks)addrs_test.go(2 hunks)as_test.go(6 hunks)context_test.go(10 hunks)errgroup_test.go(4 hunks)errors_test.go(11 hunks)internal/build/cspell.json(4 hunks)lists_test.go(14 hunks)maps_test.go(25 hunks)panic.go(1 hunks)panic_test.go(8 hunks)panicerror_test.go(2 hunks)slices_test.go(12 hunks)spinlock_test.go(5 hunks)stack_test.go(8 hunks)testing.go(1 hunks)testing_test.go(1 hunks)testutils_test.go(0 hunks)waitgroup_test.go(6 hunks)zero_test.go(2 hunks)
💤 Files with no reviewable changes (1)
- testutils_test.go
✅ Files skipped from review due to trivial changes (4)
- internal/build/cspell.json
- slices_test.go
- errors_test.go
- stack_test.go
🚧 Files skipped from review as they are similar to previous changes (11)
- lists_test.go
- panic.go
- AGENT.md
- addrs_test.go
- context_test.go
- spinlock_test.go
- as_test.go
- waitgroup_test.go
- maps_test.go
- panicerror_test.go
- errgroup_test.go
🧰 Additional context used
📓 Path-based instructions (5)
**/*
📄 CodeRabbit Inference Engine (AGENT.md)
**/*: Remove trailing whitespace from all text files.
Ensure files end with a newline.
Files:
TESTING_core.mdpanic_test.gotesting_test.gotesting.gozero_test.goREADME.mdTESTING.md
**/*.md
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.md: Run Markdownlint on Markdown files with configuration ininternal/build/markdownlint.json.
Enforce 80-character line limits and strict formatting rules in Markdown files.
Allow only a selective HTML allowlist (comments, br, kbd, etc.) in Markdown files.
Run LanguageTool grammar and style checking on Markdown files using British English configuration ininternal/build/languagetool.cfg.
Markdown files must comply with LanguageTool (grammar), CSpell (spelling), and Markdownlint (formatting) standards.
End all bullet points in Markdown files with periods for consistency.
Capitalize proper nouns correctly (JavaScript, TypeScript, Markdown) in Markdown files.
Use consistent punctuation in examples and lists in Markdown files.
Files:
TESTING_core.mdREADME.mdTESTING.md
**/*.{md,go}
📄 CodeRabbit Inference Engine (AGENT.md)
Check spelling in both Markdown and Go source files using CSpell with configuration in
internal/build/cspell.json.
Files:
TESTING_core.mdpanic_test.gotesting_test.gotesting.gozero_test.goREADME.mdTESTING.md
**/*.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.go: Enforce strict linting rules via revive with configuration ininternal/build/revive.toml.
Max function length: 40 lines.
Max function results: 3.
Max arguments: 5.
Cognitive complexity: 7.
Cyclomatic complexity: 10.
Field alignment optimization for struct definitions using thefieldalignmenttool.
Files:
panic_test.gotesting_test.gotesting.gozero_test.go
**/*_test.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*_test.go: Use test helper functions defined intestutils_test.goto reduce boilerplate and improve test consistency.
UseAssertEqual[T](t, expected, actual, msg...)for generic value comparison in tests.
UseAssertSliceEqual[T](t, expected, actual, msg...)for slice comparison in tests.
UseAssertError(t, err, expectError, msg...)for standardized error expectation checking in tests.
UseAssertBool(t, actual, expected, msg...)for boolean assertions in tests.
UseAssertPanic(t, fn, expectedPanic, msg...)for simplified panic testing in tests.
UseAssertNoPanic(t, fn, msg...)to ensure functions don't panic in tests.
UseRunConcurrentTest(t, numWorkers, workerFn)for concurrent testing with goroutines.
UseRunBenchmark(b, setupFn, execFn)for benchmark testing with setup/execution phases.
UseRunTestCases(t, []TestCase)for table-driven test runners.
Files:
panic_test.gotesting_test.gozero_test.go
🧠 Learnings (28)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `README.md` to reflect significant changes in functionality or API.
Applied to files:
TESTING_core.mdREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `assertequal[t](t, expected, actual, msg...)` for generic value compar...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Applied to files:
TESTING_core.mdpanic_test.gotesting_test.gotesting.gozero_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*.go : everything is in the `core` package, no subpackages....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: Applies to **/*.go : Everything is in the `core` package, no subpackages.
Applied to files:
TESTING_core.md
📚 Learning: applies to **/*_test.go : use `asserterror(t, err, expecterror, msg...)` for standardized error expe...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Applied to files:
TESTING_core.mdpanic_test.gotesting_test.gotesting.gozero_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `assertpanic(t, fn, expectedpanic, msg...)` for simplified panic testi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Applied to files:
TESTING_core.mdpanic_test.gotesting_test.gotesting.gozero_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `assertsliceequal[t](t, expected, actual, msg...)` for slice compariso...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Applied to files:
TESTING_core.mdpanic_test.gotesting_test.gotesting.gozero_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use test helper functions defined in `testutils_test.go` to reduce boilerp...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Applied to files:
TESTING_core.mdpanic_test.gotesting_test.gotesting.gozero_test.goREADME.mdTESTING.md
📚 Learning: in the darvaza.org/core module, the spinlock type is being deprecated in favor of darvaza.org/x/sync...
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.
Applied to files:
TESTING_core.md
📚 Learning: applies to **/*_test.go : use `assertbool(t, actual, expected, msg...)` for boolean assertions in te...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Applied to files:
TESTING_core.mdpanic_test.gotesting_test.gotesting.gozero_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `assertnopanic(t, fn, msg...)` to ensure functions don't panic in test...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Applied to files:
TESTING_core.mdpanic_test.gotesting_test.gotesting.gozero_test.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `runtestcases(t, []testcase)` for table-driven test runners....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Applied to files:
TESTING_core.mdpanic_test.gotesting_test.gotesting.gozero_test.goREADME.mdTESTING.md
📚 Learning: extensive use of go 1.23+ generics for type-safe utilities....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Applied to files:
TESTING_core.mdtesting.gozero_test.goREADME.md
📚 Learning: applies to **/*.go : cyclomatic complexity: 10....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cyclomatic complexity: 10.
Applied to files:
panic_test.go
📚 Learning: when suggesting refactoring of build scripts, consider the possibility of nested `go.mod` files with...
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.
Applied to files:
panic_test.go
📚 Learning: `errnilreceiver`, defined in `errors.go`, is intended for use by other packages even if it's not use...
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.
Applied to files:
panic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*.go : cognitive complexity: 7....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cognitive complexity: 7.
Applied to files:
panic_test.gotesting.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runconcurrenttest(t, numworkers, workerfn)` for concurrent testing wi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
Applied to files:
testing_test.gotesting.goREADME.mdTESTING.md
📚 Learning: applies to **/*_test.go : use `runbenchmark(b, setupfn, execfn)` for benchmark testing with setup/ex...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunBenchmark(b, setupFn, execFn)` for benchmark testing with setup/execution phases.
Applied to files:
testing_test.gotesting.go
📚 Learning: helper functions like `s[t]()` create test slices....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Helper functions like `S[T]()` create test slices.
Applied to files:
zero_test.go
📚 Learning: in `list.go`, the `list[t]` methods `len` and `foreach` handle a nil receiver gracefully....
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.
Applied to files:
zero_test.goREADME.md
📚 Learning: in go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as ...
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.
Applied to files:
zero_test.goREADME.md
📚 Learning: in the go `core` package's `list.go` file, the method `unsafeforeachelement` in `list[t]` does not n...
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.
Applied to files:
zero_test.go
📚 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-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
README.mdTESTING.md
📚 Learning: review documentation changes for missing articles, punctuation, and compound modifier hyphenation....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Review documentation changes for missing articles, punctuation, and compound modifier hyphenation.
Applied to files:
README.md
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
README.md
📚 Learning: integrate whitespace and eof fixes with `make fmt` for non-go files....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Integrate whitespace and EOF fixes with `make fmt` for non-Go files.
Applied to files:
README.md
📚 Learning: always run `make tidy` first before committing: fix all issues (go formatting, whitespace, cspell, m...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: ALWAYS run `make tidy` first before committing: fix all issues (Go formatting, whitespace, CSpell, markdownlint, shellcheck).
Applied to files:
README.mdTESTING.md
🧬 Code Graph Analysis (2)
panic_test.go (3)
panic.go (4)
Recovered(8-11)AsRecovered(15-28)Must(94-99)Maybe(115-117)testing.go (8)
T(20-24)AssertEqual(135-144)AssertError(193-196)AssertNoError(206-209)AssertSliceEqual(155-164)S(97-102)AssertTrue(273-276)AssertTypeIs(321-330)panicerror.go (1)
PanicError(16-19)
testing_test.go (2)
testing.go (18)
T(20-24)S(97-102)AssertSliceEqual(155-164)MockT(28-35)AssertEqual(135-144)AssertContains(174-183)AssertError(193-196)AssertNoError(206-209)AssertNil(340-349)AssertNotNil(359-368)AssertErrorIs(302-311)AssertTypeIs(321-330)AssertPanic(220-237)AssertNoPanic(248-261)RunConcurrentTest(380-386)TestCase(106-109)RunTestCases(117-124)RunBenchmark(398-405)compounderror.go (1)
Errors(10-13)
🪛 LanguageTool
README.md
[style] ~213-~213: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... keys in the map. * SortedKeys[K,T]() returns a sorted slice of the keys. * `SortedVa...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~214-~214: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ce of the keys. * SortedValues[K,T]() returns values sorted by key. * `SortedValuesCo...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~215-~215: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ted by key. * SortedValuesCond[K,T]() returns filtered values sorted by key. * `Sorte...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
TESTING.md
[grammar] ~487-~487: Consider using “to” with “prefer”.
Context: ...t.Helper() in all helper functions. - Prefer table-driven tests over individual test functions. - Keep setup and clean-...
(PREFER_OVER_TO)
🔇 Additional comments (17)
README.md (3)
22-29: Excellent documentation formatting improvements.The addition of periods to bullet points maintains consistent punctuation throughout the document, aligning with the established style guidelines.
293-313: Well-documented Must/Maybe utilities section.The new section clearly explains the purpose and usage patterns of the Must/Maybe utilities with practical examples. The documentation effectively communicates when to use each function and provides clear code examples.
424-479: Comprehensive testing utilities documentation.The new Testing Utilities section provides excellent coverage of the testing framework features, including a quick reference guide and links to detailed documentation. This will help users understand and adopt the testing utilities effectively.
TESTING_core.md (1)
1-526: Excellent comprehensive testing documentation.This document provides exceptional guidance for testing the core package utilities. The content is well-structured with:
- Clear explanation of assertion function hierarchy and dependencies
- Practical examples showing both correct and incorrect testing patterns
- Comprehensive coverage of core-specific testing scenarios
- Detailed guidelines for avoiding circular dependencies
- Excellent code examples demonstrating proper usage
The documentation effectively bridges the gap between general testing guidelines and specific requirements for testing the core utilities themselves. The hierarchy diagrams and anti-pattern examples are particularly valuable for maintainers.
TESTING.md (1)
1-577: Outstanding comprehensive testing guidelines.This document establishes excellent testing standards for all darvaza.org projects. The content is thorough and well-organised, covering:
- Clear core testing principles
- Comprehensive utility function documentation
- Detailed test structure patterns with practical examples
- Complexity management strategies
- Best practices and forbidden patterns
The guidelines will ensure consistency and maintainability across the entire ecosystem.
testing_test.go (3)
1-481: Comprehensive and well-structured test suite.This test file excellently validates the testing utilities with:
- Complete coverage: Tests all assertion functions with both success and failure cases
- Proper MockT testing: Validates error/log recording, helper method invocation, and reset functionality
- Thread-safe concurrency testing: Uses
sync/atomicfor safe counter access, addressing race conditions- Generic type testing: Validates the
Shelper with different types (int, string, empty slices)- Realistic scenarios: Tests practical usage patterns like error chaining and type assertions
The test structure follows the established patterns from the documentation, using appropriate helper functions and clear assertions. The atomic operations for concurrent testing ensure reliable execution under race detection.
317-325: Excellent use of atomic operations for thread safety.The use of
atomic.AddInt64andatomic.LoadInt64properly addresses the race condition that was mentioned in the PR objectives. This ensures reliable test execution under race detection while testing concurrent functionality.
352-364: Well-designed TestCase interface validation.The mock test case implementation effectively validates that the
RunTestCasesfunction properly executes all test cases. The design using acalledflag to track execution is simple and effective for verifying the test runner's behaviour.panic_test.go (2)
446-662: Excellent implementation of Must/Maybe tests!The new test implementations are well-structured with:
- Good use of generics to reduce code duplication
- Comprehensive type coverage
- Proper use of the new assertion helpers
- Clear test case organisation
70-75: Use AssertNil for consistency with new testing patterns.Replace the manual nil check with the standardised assertion helper.
func (asRecoveredTestCase) checkNilResult(t *testing.T, result Recovered) { t.Helper() - if result != nil { - t.Fatalf("expected nil, got %v", result) - } + AssertNil(t, result, "result") }⛔ Skipped due to learnings
Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.Learnt from: CR PR: darvaza-proxy/core#0 File: AGENT.md:0-0 Timestamp: 2025-07-30T02:57:51.092Z Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.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#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.testing.go (4)
18-83: Well-designed testing interface and mock implementation.The T interface and MockT implementation provide excellent abstraction for testing utilities with comprehensive state tracking and inspection capabilities.
126-368: Excellent implementation of assertion helpers.The assertion functions are consistently implemented with:
- Proper use of generics for type safety
- Clear error messages
- Success logging for debugging
- Comprehensive documentation with examples
370-386: Well-implemented concurrent testing utilities.The concurrent testing helpers properly manage goroutines and error collection with correct synchronisation.
Also applies to: 443-465
407-441: Parameter count exceeds guidelines but is acknowledged.The
doMessagefunction has 6 parameters (guideline: max 5), but this is acknowledged with the revive:disable comment. The design provides necessary flexibility for message formatting.zero_test.go (3)
10-127: Excellent use of generics to reduce test duplication.The generic test case structures and helper functions significantly improve code reuse and maintainability. Good use of the factory pattern for test case creation.
176-446: Comprehensive test coverage for IsZero function.Excellent test organisation with:
- Complete coverage of all Go types
- Well-structured edge cases
- Clear test naming
- Proper use of the ST helper
448-643: Well-structured IsNil tests with excellent coverage.The tests are properly organised by type category with comprehensive coverage including typed nil values and edge cases.
Update: Fixed Circular Dependencies and Enhanced DocumentationChanges since last push: 🔧 Fixed Circular Testing Dependencies
📚 Enhanced Documentation Structure
🎯 Key Improvements
Files changed:
Total: +150 lines of documentation improvements and circular dependency fixes. This update addresses the original PR review bot concern while establishing robust documentation standards for the entire darvaza.org ecosystem. |
- Replace `wantok` with proper camelCase `wantOK` in test structs. - Remove redundant camelCase/PascalCase terms from cspell dictionary. - Remove British English words that cspell recognizes automatically. - Sort dictionary entries alphabetically for better maintainability. Signed-off-by: Alejandro Mery <amery@apply.co>
…mprehensive utilities Transform private testing helpers into a comprehensive public testing infrastructure that provides type-safe assertion utilities, mock testing capabilities, and standardised testing patterns for the entire darvaza.org ecosystem. **New Public Testing API (testing.go - 517 lines):** - **T interface**: Abstracts testing functionality for both *testing.T and MockT - **MockT implementation**: Thread-safe mock with error/log collection, helper tracking, state inspection, and reset capabilities - **14 assertion functions**: AssertEqual, AssertError/AssertNoError, AssertPanic, AssertTrue/AssertFalse, AssertNil, AssertTypeIs, AssertErrorIs, etc. - **Utility functions**: S[T]() slice creation, RunConcurrentTest, RunBenchmark, RunTestCases for table-driven tests - **Generic support**: Type-safe assertions using Go generics - **Success logging**: All assertions log successful results for debugging **Self-Testing Infrastructure (testing_test.go - 596 lines):** - Tests the testing utilities themselves using MockT to avoid circular dependencies - Validates MockT functionality, assertion behaviour, and error handling patterns - Ensures the public testing API works correctly with comprehensive coverage **Test Migration and API Standardisation (8 files):** - Migrate from AssertBool(t, actual, expected) to AssertTrue/AssertFalse/AssertEqual - Replace AssertError(t, err, bool, msg) with AssertError/AssertNoError pattern - Standardise parameter order to (t, expected, actual, message) across all functions - Updated: context_test.go, errors_test.go, lists_test.go, panic_test.go, slices_test.go, spinlock_test.go, zero_test.go **Documentation Expansion:** - **AGENT.md**: Add 100+ lines documenting testing patterns, assertion functions, MockT usage examples, and API migration guides - **README.md**: Add 50+ lines documenting public testing utilities with quick reference and feature overview - **cspell.json**: Add "Logf" for MockT.Logf method **Code Quality Improvements:** - Consistent error message prefixes with descriptive formatting - Better string formatting using %q for clarity - Thread-safe implementations with proper synchronisation - Extensive self-validation and testing of testing utilities **Architectural Impact:** - **Remove testutils_test.go**: Migrate all private utilities to public API - **External reusability**: Other darvaza.org packages can import testing utilities - **Ecosystem consistency**: Unified testing patterns across all projects - **Enhanced debugging**: Success logging provides better test diagnostics - **Quality enforcement**: Standardised patterns with strict linting compliance This transformation elevates testing from ad-hoc internal tooling to a first-class, well-engineered public API with self-validation capabilities that serves the entire darvaza.org ecosystem. Signed-off-by: Alejandro Mery <amery@apply.co>
PR Branch updateThis PR has been rebased and updated with the latest changes from the 🔄 Merged Changes
📊 Impact Summary
✅ Quality Assurance
The PR is now current with the latest development standards and ready |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
README.md (2)
293-327: Fix British English spelling for consistencyThe documentation is excellent, but please update 'ok' to 'OK' on lines 304 and 306 to maintain British English consistency throughout the documentation.
- err is not nil. Follows the common Go pattern of Must* functions for cases + err is not nil. Follows the common Go pattern of Must* functions for cases -* `MustOK[T](value T, ok bool) T` - returns value or panics with `PanicError` if - ok is false. Useful for operations that should always succeed, such as map +* `MustOK[T](value T, ok bool) T` - returns value or panics with `PanicError` if + OK is false. Useful for operations that should always succeed, such as map -* `MaybeOK[T](value T, ok bool) T` - always returns the value, ignoring the ok - flag. Useful when you want to proceed with a default or zero value regardless +* `MaybeOK[T](value T, ok bool) T` - always returns the value, ignoring the OK + flag. Useful when you want to proceed with a default or zero value regardless
479-482: Maintain British English consistencyPlease update 'ok' to 'OK' on line 482 for consistency with British English standards.
- `errors.Is`. * `AssertTypeIs[T](t, value, msg...)` - type assertion with casting, returns - (value, ok). + (value, OK).errgroup_test.go (1)
184-189: Use assertion helper for consistency.Replace direct t.Error call with AssertTrue to maintain consistency with the rest of the test file.
func (tc errGroupGoTestCase) checkCancellation(t *testing.T, eg *ErrGroup) { t.Helper() - if tc.expectCancel && !eg.IsCancelled() { - t.Error("Expected group to be cancelled") - } + if tc.expectCancel { + AssertTrue(t, eg.IsCancelled(), "group cancelled") + } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (27)
AGENT.md(2 hunks)README.md(3 hunks)TESTING.md(1 hunks)TESTING_core.md(1 hunks)addrport_test.go(6 hunks)addrs_test.go(10 hunks)as_test.go(11 hunks)compounderror_test.go(10 hunks)context_test.go(10 hunks)errgroup_test.go(5 hunks)errors_test.go(21 hunks)generics_test.go(14 hunks)internal/build/cspell.json(2 hunks)lists_test.go(8 hunks)maps_test.go(27 hunks)panic.go(1 hunks)panic_test.go(5 hunks)panicerror_test.go(10 hunks)slices_test.go(10 hunks)spinlock_test.go(5 hunks)splithostport_test.go(17 hunks)stack_test.go(20 hunks)testing.go(1 hunks)testing_test.go(1 hunks)testutils_test.go(0 hunks)waitgroup_test.go(6 hunks)zero_test.go(4 hunks)
💤 Files with no reviewable changes (1)
- testutils_test.go
🚧 Files skipped from review as they are similar to previous changes (9)
- internal/build/cspell.json
- AGENT.md
- context_test.go
- errors_test.go
- testing_test.go
- maps_test.go
- slices_test.go
- stack_test.go
- waitgroup_test.go
🧰 Additional context used
📓 Path-based instructions (5)
**/*.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.go: Enforce strict linting rules via revive with configuration ininternal/build/revive.toml.
Max function length: 40 lines.
Max function results: 3.
Max arguments: 5.
Cognitive complexity: 7.
Cyclomatic complexity: 10.
Field alignment optimization for struct definitions using thefieldalignmenttool.
Files:
panic.gospinlock_test.goaddrs_test.gosplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.go
**/*
📄 CodeRabbit Inference Engine (AGENT.md)
**/*: Remove trailing whitespace from all text files.
Ensure files end with a newline.
Files:
panic.gospinlock_test.goTESTING.mdaddrs_test.goTESTING_core.mdsplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.goREADME.md
**/*.{md,go}
📄 CodeRabbit Inference Engine (AGENT.md)
Check spelling in both Markdown and Go source files using CSpell with configuration in
internal/build/cspell.json.
Files:
panic.gospinlock_test.goTESTING.mdaddrs_test.goTESTING_core.mdsplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.goREADME.md
**/*_test.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*_test.go: Use test helper functions defined intestutils_test.goto reduce boilerplate and improve test consistency.
UseAssertEqual[T](t, expected, actual, msg...)for generic value comparison in tests.
UseAssertSliceEqual[T](t, expected, actual, msg...)for slice comparison in tests.
UseAssertError(t, err, expectError, msg...)for standardized error expectation checking in tests.
UseAssertBool(t, actual, expected, msg...)for boolean assertions in tests.
UseAssertPanic(t, fn, expectedPanic, msg...)for simplified panic testing in tests.
UseAssertNoPanic(t, fn, msg...)to ensure functions don't panic in tests.
UseRunConcurrentTest(t, numWorkers, workerFn)for concurrent testing with goroutines.
UseRunBenchmark(b, setupFn, execFn)for benchmark testing with setup/execution phases.
UseRunTestCases(t, []TestCase)for table-driven test runners.
Files:
spinlock_test.goaddrs_test.gosplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.go
**/*.md
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.md: Run Markdownlint on Markdown files with configuration ininternal/build/markdownlint.json.
Enforce 80-character line limits and strict formatting rules in Markdown files.
Allow only a selective HTML allowlist (comments, br, kbd, etc.) in Markdown files.
Run LanguageTool grammar and style checking on Markdown files using British English configuration ininternal/build/languagetool.cfg.
Markdown files must comply with LanguageTool (grammar), CSpell (spelling), and Markdownlint (formatting) standards.
End all bullet points in Markdown files with periods for consistency.
Capitalize proper nouns correctly (JavaScript, TypeScript, Markdown) in Markdown files.
Use consistent punctuation in examples and lists in Markdown files.
Files:
TESTING.mdTESTING_core.mdREADME.md
🧠 Learnings (29)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
📚 Learning: extensive use of go 1.23+ generics for type-safe utilities....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Applied to files:
panic.goTESTING_core.mdtesting.gogenerics_test.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertnopanic(t, fn, msg...)` to ensure functions don't panic in test...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Applied to files:
panic.gospinlock_test.goTESTING.mdaddrs_test.goTESTING_core.mdsplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertpanic(t, fn, expectedpanic, msg...)` for simplified panic testi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Applied to files:
panic.gospinlock_test.goTESTING.mdaddrs_test.goTESTING_core.mdsplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.goREADME.md
📚 Learning: applies to **/*.go : everything is in the `core` package, no subpackages....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: Applies to **/*.go : Everything is in the `core` package, no subpackages.
Applied to files:
panic.goTESTING_core.md
📚 Learning: applies to **/*.go : cyclomatic complexity: 10....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cyclomatic complexity: 10.
Applied to files:
panic.goaddrs_test.goTESTING_core.mdcompounderror_test.gopanicerror_test.goerrgroup_test.gopanic_test.goREADME.md
📚 Learning: applies to **/*.go : cognitive complexity: 7....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cognitive complexity: 7.
Applied to files:
panic.goaddrs_test.goTESTING_core.mdcompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gozero_test.go
📚 Learning: applies to **/*.go : max arguments: 5....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Max arguments: 5.
Applied to files:
panic.go
📚 Learning: applies to **/*_test.go : use `asserterror(t, err, expecterror, msg...)` for standardized error expe...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Applied to files:
panic.gospinlock_test.goTESTING.mdaddrs_test.goTESTING_core.mdsplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.goREADME.md
📚 Learning: in go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as ...
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.
Applied to files:
panic.gogenerics_test.gozero_test.goREADME.md
📚 Learning: `errnilreceiver`, defined in `errors.go`, is intended for use by other packages even if it's not use...
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.
Applied to files:
panic.goREADME.md
📚 Learning: in the darvaza.org/core module, the spinlock type is being deprecated in favor of darvaza.org/x/sync...
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.
Applied to files:
spinlock_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runtestcases(t, []testcase)` for table-driven test runners....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Applied to files:
spinlock_test.goTESTING.mdaddrs_test.goTESTING_core.mdsplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertsliceequal[t](t, expected, actual, msg...)` for slice compariso...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Applied to files:
spinlock_test.goTESTING.mdaddrs_test.goTESTING_core.mdsplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.goREADME.md
📚 Learning: applies to **/*_test.go : use test helper functions defined in `testutils_test.go` to reduce boilerp...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Applied to files:
spinlock_test.goTESTING.mdaddrs_test.goTESTING_core.mdsplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertequal[t](t, expected, actual, msg...)` for generic value compar...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Applied to files:
spinlock_test.goTESTING.mdaddrs_test.goTESTING_core.mdsplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runconcurrenttest(t, numworkers, workerfn)` for concurrent testing wi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
Applied to files:
spinlock_test.goTESTING.mdaddrs_test.gosplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertbool(t, actual, expected, msg...)` for boolean assertions in te...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Applied to files:
spinlock_test.goTESTING.mdaddrs_test.goTESTING_core.mdsplithostport_test.goaddrport_test.golists_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.gogenerics_test.gopanic_test.gozero_test.goas_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runbenchmark(b, setupfn, execfn)` for benchmark testing with setup/ex...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunBenchmark(b, setupFn, execFn)` for benchmark testing with setup/execution phases.
Applied to files:
spinlock_test.goaddrs_test.gosplithostport_test.goaddrport_test.gocompounderror_test.gopanicerror_test.gotesting.goerrgroup_test.goas_test.go
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `README.md` to reflect significant changes in functionality or API.
Applied to files:
TESTING.mdTESTING_core.mdREADME.md
📚 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-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
TESTING.mdREADME.md
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
TESTING.mdREADME.md
📚 Learning: table-driven tests are preferred....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Table-driven tests are preferred.
Applied to files:
TESTING.md
📚 Learning: verify all tests pass with `make test` before committing....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Verify all tests pass with `make test` before committing.
Applied to files:
TESTING.md
📚 Learning: when suggesting refactoring of build scripts, consider the possibility of nested `go.mod` files with...
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.
Applied to files:
addrs_test.goerrgroup_test.go
📚 Learning: in the go `core` package's `list.go` file, the method `unsafeforeachelement` in `list[t]` does not n...
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.
Applied to files:
lists_test.go
📚 Learning: in `list.go`, the `list[t]` methods `len` and `foreach` handle a nil receiver gracefully....
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.
Applied to files:
lists_test.gozero_test.go
📚 Learning: helper functions like `s[t]()` create test slices....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Helper functions like `S[T]()` create test slices.
Applied to files:
generics_test.gozero_test.goas_test.go
📚 Learning: update documentation when adding new tools or changing workflows....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Update documentation when adding new tools or changing workflows.
Applied to files:
README.md
🧬 Code Graph Analysis (10)
panic.go (1)
panicerror.go (2)
NewPanicWrap(73-78)NewPanicError(45-53)
spinlock_test.go (2)
testing.go (7)
TestCase(158-161)T(20-28)AssertEqual(187-196)RunTestCases(169-176)AssertNoError(278-281)AssertPanic(292-309)AssertNoPanic(320-333)sync.go (1)
SpinLock(13-13)
splithostport_test.go (1)
testing.go (3)
TestCase(158-161)T(20-28)RunTestCases(169-176)
addrport_test.go (2)
testing.go (4)
TestCase(158-161)T(20-28)RunTestCases(169-176)S(149-154)addrport.go (1)
AddrPort(20-49)
lists_test.go (2)
testing.go (7)
TestCase(158-161)T(20-28)AssertEqual(187-196)S(149-154)RunTestCases(169-176)AssertFalse(360-363)AssertTrue(345-348)lists.go (3)
ListContains(8-12)ListContainsFn(16-26)ListCopyFn(106-125)
compounderror_test.go (1)
testing.go (4)
TestCase(158-161)S(149-154)T(20-28)RunTestCases(169-176)
errgroup_test.go (2)
testing.go (7)
TestCase(158-161)T(20-28)RunTestCases(169-176)AssertError(265-268)AssertNoError(278-281)AssertTrue(345-348)AssertEqual(187-196)sync.go (1)
ErrGroup(128-135)
generics_test.go (1)
testing.go (4)
TestCase(158-161)T(20-28)S(149-154)RunTestCases(169-176)
panic_test.go (4)
testing.go (13)
TestCase(158-161)T(20-28)AssertNil(412-421)AssertNotNil(431-440)AssertTypeIs(393-402)AssertEqual(187-196)RunTestCases(169-176)AssertError(265-268)AssertNoError(278-281)AssertTrue(345-348)AssertSliceEqual(227-236)S(149-154)AssertContains(246-255)zero.go (1)
IsNil(132-145)panicerror.go (2)
NewPanicError(45-53)PanicError(16-19)panic.go (8)
AsRecovered(15-28)Recovered(8-11)Catcher(31-33)Catch(78-81)Must(94-99)Maybe(115-117)MustOK(133-138)MaybeOK(154-156)
as_test.go (2)
testing.go (4)
TestCase(158-161)T(20-28)RunTestCases(169-176)S(149-154)as.go (1)
As(4-7)
🪛 LanguageTool
TESTING.md
[style] ~52-~52: Would you like to use the Oxford spelling “standardized”? The spelling ‘standardised’ is also correct.
Context: ...and generic RunTestCases function for standardised table-driven tests: ```go // TestCase ...
(OXFORD_SPELLING_Z_NOT_S)
[style] ~501-~501: Would you like to use the Oxford spelling “specialized”? The spelling ‘specialised’ is also correct.
Context: ...ty and improve readability by providing specialised factory functions that match common usa...
(OXFORD_SPELLING_Z_NOT_S)
[uncategorized] ~502-~502: Possible missing comma found.
Context: ...ctory functions that match common usage patterns rather than forcing all callers to prov...
(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~722-~722: Would you like to use the Oxford spelling “centralized”? The spelling ‘centralised’ is also correct.
Context: ...inability**: Complex test data logic is centralised. 4. Readability: Test functions foc...
(OXFORD_SPELLING_Z_NOT_S)
[style] ~724-~724: Would you like to use the Oxford spelling “Parameterization”? The spelling ‘Parameterisation’ is also correct.
Context: ...ocus on execution, not data setup. 5. Parameterisation: Easy to create variations of test su...
(OXFORD_SPELLING_Z_NOT_S)
[grammar] ~919-~919: Consider using “to” with “prefer”.
Context: ...t.Helper() in all helper functions. - Prefer table-driven tests over individual test functions. - Keep setup and clean-...
(PREFER_OVER_TO)
README.md
[locale-violation] ~304-~304: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... value or panics with PanicError if ok is false. Useful for operations that sh...
(OK)
[locale-violation] ~306-~306: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... always returns the value, ignoring the ok flag. Useful when you want to proceed...
(OK)
[grammar] ~479-~479: This sentence seems to be incomplete. Insert a noun before ‘Is’ to make the sentence complete.
Context: ...t, msg...)- error chain checking with errors.Is. * AssertTypeIs[T](t, value, msg...)`...
(MISSING_SUBJECT)
[locale-violation] ~482-~482: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ...sertion with casting, returns (value, ok). * `AssertPanic(t, fn, expectedPanic, ...
(OK)
[style] ~488-~488: Would you like to use the Oxford spelling “standardized”? The spelling ‘standardised’ is also correct.
Context: ...ing Utilities * TestCase interface - standardised interface for table-driven tests with ...
(OXFORD_SPELLING_Z_NOT_S)
🔇 Additional comments (63)
testing.go (7)
12-28: Good abstraction with compile-time verificationThe T interface provides excellent abstraction for testing functionality, and the compile-time verification ensures both
*testing.TandMockTimplement it correctly.
30-135: Well-designed thread-safe mock implementationThe
MockTimplementation is excellent with proper thread safety, comprehensive state tracking, and useful inspection methods. The lock usage is correct throughout.
137-154: Useful slice creation helperThe
Sfunction provides a clean, generic way to create slices with proper handling of empty slices. The documentation with examples is particularly helpful.
156-176: Excellent standardisation of table-driven testsThe
TestCaseinterface andRunTestCasesfunction provide a clean, type-safe way to implement table-driven tests whilst eliminating boilerplate code.
178-440: Comprehensive and well-designed assertion libraryThe assertion functions provide excellent coverage with consistent design patterns:
- Proper use of
t.Helper()for accurate error locations- Boolean returns enable flexible usage patterns
- Generic implementations ensure type safety
- Consistent error/success logging enhances debugging
Particularly good handling of edge cases in
AssertPanicandAssertNoPanic.
442-477: Solid concurrent testing and benchmarking utilitiesBoth utilities follow established patterns:
RunConcurrentTestproperly manages goroutines and error collectionRunBenchmarkcorrectly handles setup phase with timer reset
479-537: Well-structured helper functionsThe internal helpers are properly organised:
- Justified use of lint suppression for
doMessageparameter count- Clean separation of concerns between formatting and output
- Proper goroutine and channel management in concurrent helpers
panic.go (4)
83-99: Well-implemented Must utilityThe
Mustfunction correctly implements the common Go pattern with proper panic handling and stack trace management. The documentation with examples clearly communicates appropriate use cases.
101-117: Simple and effective Maybe utilityClean implementation of the error-ignoring pattern with clear documentation about when this approach is appropriate.
119-138: Correct MustOK implementationThe function properly handles the boolean flag pattern with appropriate panic behavior. Good use of lint suppression for the standard Go 'ok' pattern.
140-156: Clean MaybeOK implementationSimple and effective implementation that mirrors the Maybe pattern for boolean flags.
spinlock_test.go (4)
10-30: Good adoption of standardised test patternsThe compile-time interface verification and factory functions follow the new testing patterns consistently, improving maintainability.
43-57: Clean implementation of TestCase interfaceThe refactored test methods properly implement the interface with cleaner assertions and standardised test execution.
86-132: Effective use of concurrent testing utilitiesThe refactoring properly leverages
RunConcurrentTestand standardised assertions whilst maintaining the original test logic.
169-197: Simplified panic testing with new assertionsThe use of
AssertPanicandAssertNoPanicmakes the tests more readable and maintainable.lists_test.go (5)
8-35: Excellent modularisation with helper functionsThe extraction of iteration test logic into helper functions significantly reduces duplication and improves maintainability.
131-176: Clean TestCase implementation with improved assertionsThe refactoring to use factory functions and more specific assertions (
AssertEqual,AssertFalse) makes the tests clearer and more maintainable.
257-292: Well-structured test decompositionBreaking down tests into focused helper functions improves readability and makes debugging easier.
363-418: Excellent extraction of common test patternsThe helper functions for nil and early return cases eliminate duplication whilst maintaining clarity. The consistent structure makes the tests easy to understand and maintain.
8-487: Comprehensive test refactoring following new standardsThis refactoring successfully transforms the list tests to follow the new testing patterns whilst improving modularity and reducing duplication. The consistent use of helpers, factory functions, and standardised assertions makes the test suite more maintainable.
README.md (2)
438-505: Excellent documentation of testing utilitiesThe testing utilities documentation is comprehensive, well-structured, and includes practical examples. The cross-references to TESTING.md and TESTING_core.md provide good navigation for users.
535-549: Helpful development sectionThe addition of the Development section with quick start commands provides excellent guidance for new contributors.
addrport_test.go (5)
9-11: Excellent compile-time interface verification!Adding these compile-time assertions ensures that the test case structs properly implement the
TestCaseinterface, catching any missing methods at compile time rather than runtime.
93-100: LGTM - Clean constructor pattern!The factory function provides a consistent way to create test cases and improves readability compared to inline struct literals.
102-116: Perfect TestCase interface implementation!The
Name()andTest()methods correctly implement theTestCaseinterface whilst preserving the original test logic. Thet.Helper()call is appropriately maintained for proper stack traces.
119-119: Great use of the generic test runner!Replacing manual iteration with
RunTestCasesreduces boilerplate and ensures consistent test execution patterns across the codebase.
146-174: Consistent refactoring applied throughout!The same high-quality pattern is applied to
typeSpecificAddrPortTestCase, maintaining consistency across all test case types in the file.TESTING_core.md (3)
10-108: Exceptional documentation of assertion hierarchy!This section brilliantly explains the internal dependencies between assertion functions and provides clear guidance on avoiding circular testing patterns. The visual hierarchy diagram and practical examples make this highly valuable for maintainers.
112-178: Comprehensive MockT documentation!The detailed explanation of MockT features with practical examples provides excellent guidance for testing assertion functions. The thread-safety notes and state management examples are particularly valuable.
179-568: Comprehensive testing guidance for core package!The remaining sections provide excellent coverage of core-specific testing patterns including generics, error handling, synchronization primitives, and performance testing. The emphasis on zero dependencies and self-consistency aligns perfectly with the core package's role as a foundational library.
splithostport_test.go (4)
8-16: Thorough compile-time interface verification!All test case types are properly verified to implement the
TestCaseinterface, ensuring compile-time safety across the entire file.
26-44: Consistent TestCase implementation pattern!The
Name()andTest()method implementations maintain the original test logic whilst conforming to theTestCaseinterface. The pattern is applied consistently across all test case types.
76-76: Excellent adoption of generic test runner!The consistent use of
RunTestCasesacross all test functions eliminates boilerplate and ensures uniform test execution patterns throughout the file.
470-536: Complete and consistent refactoring throughout!The standardization is applied uniformly across all test case types in the file, creating a cohesive and maintainable test suite that aligns with the project's testing framework.
compounderror_test.go (4)
9-16: Comprehensive interface verification!All test case types are properly verified to implement the
TestCaseinterface, ensuring robust compile-time checking across the entire test suite.
24-48: Well-designed constructor and helper functions!The factory functions provide consistent test case creation, and the helper functions like
newCompoundErrorErrorTestCaseEmptyreduce boilerplate for common patterns whilst maintaining clarity.
50-62: Proper TestCase interface implementation!The
Name()andTest()methods correctly implement the interface whilst maintaining the original test logic and appropriatet.Helper()calls for proper stack traces.
65-409: Successful modernisation of test suite!The consistent application of the
TestCaseinterface pattern withRunTestCasesacross all test functions creates a unified, maintainable test suite that aligns perfectly with the project's testing framework standards.TESTING.md (1)
1-1105: Excellent comprehensive testing guidelines!This document provides clear, well-structured testing standards for the darvaza.org ecosystem. The mandatory compliance requirements, detailed examples, and comprehensive coverage of testing patterns will ensure consistent, maintainable test code across all projects.
Particularly valuable aspects:
- Clear distinction between mandatory requirements and recommendations
- Extensive examples demonstrating both correct and incorrect patterns
- Detailed factory function patterns with field alignment considerations
- Comprehensive assertion function hierarchy guidelines
- Practical CI/CD integration guidance
generics_test.go (1)
8-459: Well-executed refactoring following testing guidelines!The refactoring successfully implements all mandatory TestCase compliance requirements:
- ✅ Interface validations for all test case types
- ✅ Factory functions for each test case type
- ✅ All test cases use factory functions (no naked struct literals)
- ✅ Consistent use of
RunTestCaseshelper- ✅ Helper methods properly extracted (e.g.,
evaluateYesFunction,evaluateNoFunction)The code maintains excellent readability while adhering to the new testing patterns.
as_test.go (1)
9-500: Excellent refactoring with improved maintainability!The refactoring successfully implements all testing guidelines while adding valuable improvements:
- ✅ All TestCase interface validations present
- ✅ Factory functions for every test case type
- ✅ Test logic properly decomposed into helper methods (e.g.,
testStringConversion,testIntConversion)- ✅ Consistent use of
RunTestCasesthroughoutAdditional improvements:
- Good extraction of
testHelloconstant for better maintainability- Clear helper method names that describe their purpose
- Proper use of
t.Helper()in all helper functionsaddrs_test.go (1)
10-549: Excellent refactoring with smart use of convenience factories!The refactoring successfully implements all mandatory requirements while demonstrating best practices:
- ✅ Complete TestCase interface compliance
- ✅ Smart use of convenience factory
newParseAddrTestCaseStralongside base factory- ✅ All anonymous test functions properly extracted to named helpers
- ✅ Consistent use of assertion helpers throughout
Particularly good patterns:
- The convenience factory pattern (Lines 52-63) that accepts string addresses and handles parsing internally
- Clear extraction of test logic into focused helper functions
- Proper use of
t.Helper()in all helper methodspanicerror_test.go (1)
10-516: Outstanding refactoring with excellent decomposition!This refactoring demonstrates exceptional adherence to testing guidelines:
- ✅ Complete TestCase interface compliance for all 6 test case types
- ✅ Comprehensive factory functions for every test case type
- ✅ Excellent decomposition of complex validation logic into focused helper methods
- ✅ Clear separation of concerns in test execution and validation
Particularly impressive:
- The methodical breakdown of panic validation logic (Lines 267-301)
- Clear helper method naming that describes validation purpose
- Consistent error message validation patterns
- Proper extraction of all inline test logic
errgroup_test.go (7)
10-15: Good use of compile-time interface verification.The compile-time assertions ensure that all test case types properly implement the TestCase interface, catching any interface compliance issues at build time.
23-51: Well-structured test case constructor pattern.The constructor functions and test case setup follow a consistent pattern that improves test maintainability and readability.
88-146: Excellent use of specialised constructor functions.The pattern of having specific constructors for success, error, and cancellation scenarios improves code clarity and reduces the chance of test setup errors.
158-189: Clean separation of test concerns with helper methods.The decomposition of test logic into focused helper methods improves readability and makes the test flow easier to follow.
173-182: Appropriate error handling for context cancellation.The method correctly distinguishes between expected cancellations and actual errors, providing clear test output.
448-488: Well-structured concurrent testing helpers.The separation of worker creation, execution, and validation makes the concurrent tests more maintainable and easier to understand.
291-343: Excellent organisation of cancellation tests into focused subtests.Breaking down the test into specific scenarios improves test clarity and makes failures easier to diagnose.
zero_test.go (6)
10-17: Comprehensive compile-time interface verification.All test case types are verified to implement the TestCase interface at compile time, ensuring consistency across the test suite.
18-63: Excellent use of generics for test case types.The separation between comparable and reference types with generic test cases eliminates code duplication while maintaining type safety.
122-134: Well-organised test structure by type categories.The organisation into type-specific subtests makes the test suite easier to navigate and debug.
790-834: Valuable practical examples demonstrating IsZero usage patterns.These examples effectively demonstrate real-world lazy initialisation patterns, making the purpose and usage of IsZero clear to developers.
836-891: Thorough edge case testing for nil pointers.The consistent pattern across all nil pointer test helpers ensures comprehensive coverage of edge cases.
471-554: Outstanding comparison tests clarifying IsNil vs IsZero semantics.The comprehensive test cases with clear descriptions effectively document the semantic differences between nil (uninitialised) and zero (default value) states.
panic_test.go (7)
9-21: Complete compile-time verification coverage.All test case types, including the new Must/Maybe utility tests, are verified to implement the TestCase interface.
53-92: Well-structured AsRecovered test with proper edge case handling.The test correctly handles nil inputs and the special case of string to error conversion by NewPanicError.
391-477: Excellent generic test helper design for Must function.The combination of panic recovery wrapper, generic type helpers, and type switch dispatch provides a robust and type-safe testing approach.
513-529: Thorough verification of Must panic behaviour.The test properly verifies error wrapping, panic type, and stack trace existence, ensuring robust error handling.
406-413: Good attention to struct field alignment.The consistent ordering of struct fields from large to small with explanatory comments demonstrates attention to memory efficiency.
Also applies to: 492-499, 611-619
597-806: Consistent and comprehensive MustOK/MaybeOK test implementation.The test patterns mirror the Must/Maybe tests, providing consistent coverage and maintaining the same high-quality generic helper approach.
479-806: Exceptional test coverage for new utility functions.The test suite provides comprehensive coverage of Must/Maybe/MustOK/MaybeOK functions across various types and scenarios, ensuring robust behaviour.
|
Fixed redundant argument type in newNewPanicErrorfTestCase detected by DeepSource. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
README.md (2)
304-306: Use British English "OK" instead of American "ok".For consistency with British English conventions, replace lowercase "ok" with uppercase "OK".
- ok is false. Useful for operations that should always succeed, such as map + OK is false. Useful for operations that should always succeed, such as map access or type assertions that are guaranteed to be valid. -* `MaybeOK[T](value T, ok bool) T` - always returns the value, ignoring the ok +* `MaybeOK[T](value T, ok bool) T` - always returns the value, ignoring the OK
482-482: Use British English "OK" instead of American "ok".For consistency with British English conventions.
- * panic testing. + (value, OK).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (22)
README.md(3 hunks)addrport_test.go(6 hunks)addrs_test.go(10 hunks)as_test.go(11 hunks)compounderror_test.go(10 hunks)context_test.go(10 hunks)errgroup_test.go(5 hunks)errors_test.go(21 hunks)generics_test.go(14 hunks)internal/build/cspell.json(2 hunks)lists_test.go(8 hunks)maps_test.go(27 hunks)panic.go(1 hunks)panic_test.go(5 hunks)panicerror_test.go(10 hunks)slices_test.go(10 hunks)spinlock_test.go(5 hunks)splithostport_test.go(17 hunks)stack_test.go(20 hunks)testing_test.go(1 hunks)waitgroup_test.go(6 hunks)zero_test.go(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (14)
- internal/build/cspell.json
- spinlock_test.go
- lists_test.go
- splithostport_test.go
- panic.go
- context_test.go
- addrport_test.go
- addrs_test.go
- compounderror_test.go
- as_test.go
- waitgroup_test.go
- panicerror_test.go
- errgroup_test.go
- maps_test.go
🧰 Additional context used
📓 Path-based instructions (5)
**/*.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.go: Enforce strict linting rules via revive with configuration ininternal/build/revive.toml.
Max function length: 40 lines.
Max function results: 3.
Max arguments: 5.
Cognitive complexity: 7.
Cyclomatic complexity: 10.
Field alignment optimization for struct definitions using thefieldalignmenttool.
Files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.go
**/*_test.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*_test.go: Use test helper functions defined intestutils_test.goto reduce boilerplate and improve test consistency.
UseAssertEqual[T](t, expected, actual, msg...)for generic value comparison in tests.
UseAssertSliceEqual[T](t, expected, actual, msg...)for slice comparison in tests.
UseAssertError(t, err, expectError, msg...)for standardized error expectation checking in tests.
UseAssertBool(t, actual, expected, msg...)for boolean assertions in tests.
UseAssertPanic(t, fn, expectedPanic, msg...)for simplified panic testing in tests.
UseAssertNoPanic(t, fn, msg...)to ensure functions don't panic in tests.
UseRunConcurrentTest(t, numWorkers, workerFn)for concurrent testing with goroutines.
UseRunBenchmark(b, setupFn, execFn)for benchmark testing with setup/execution phases.
UseRunTestCases(t, []TestCase)for table-driven test runners.
Files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.go
**/*
📄 CodeRabbit Inference Engine (AGENT.md)
**/*: Remove trailing whitespace from all text files.
Ensure files end with a newline.
Files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.goREADME.md
**/*.{md,go}
📄 CodeRabbit Inference Engine (AGENT.md)
Check spelling in both Markdown and Go source files using CSpell with configuration in
internal/build/cspell.json.
Files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.goREADME.md
**/*.md
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.md: Run Markdownlint on Markdown files with configuration ininternal/build/markdownlint.json.
Enforce 80-character line limits and strict formatting rules in Markdown files.
Allow only a selective HTML allowlist (comments, br, kbd, etc.) in Markdown files.
Run LanguageTool grammar and style checking on Markdown files using British English configuration ininternal/build/languagetool.cfg.
Markdown files must comply with LanguageTool (grammar), CSpell (spelling), and Markdownlint (formatting) standards.
End all bullet points in Markdown files with periods for consistency.
Capitalize proper nouns correctly (JavaScript, TypeScript, Markdown) in Markdown files.
Use consistent punctuation in examples and lists in Markdown files.
Files:
README.md
🧠 Learnings (23)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
📚 Learning: applies to **/*_test.go : use `asserterror(t, err, expecterror, msg...)` for standardized error expe...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Applied to files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runtestcases(t, []testcase)` for table-driven test runners....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Applied to files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use test helper functions defined in `testutils_test.go` to reduce boilerp...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Applied to files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertequal[t](t, expected, actual, msg...)` for generic value compar...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Applied to files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertpanic(t, fn, expectedpanic, msg...)` for simplified panic testi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Applied to files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertnopanic(t, fn, msg...)` to ensure functions don't panic in test...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Applied to files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertsliceequal[t](t, expected, actual, msg...)` for slice compariso...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Applied to files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertbool(t, actual, expected, msg...)` for boolean assertions in te...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Applied to files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runconcurrenttest(t, numworkers, workerfn)` for concurrent testing wi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
Applied to files:
errors_test.gotesting_test.goslices_test.gogenerics_test.gostack_test.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runbenchmark(b, setupfn, execfn)` for benchmark testing with setup/ex...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunBenchmark(b, setupFn, execFn)` for benchmark testing with setup/execution phases.
Applied to files:
errors_test.gotesting_test.goslices_test.gostack_test.go
📚 Learning: `errnilreceiver`, defined in `errors.go`, is intended for use by other packages even if it's not use...
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.
Applied to files:
errors_test.goREADME.md
📚 Learning: helper functions like `s[t]()` create test slices....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Helper functions like `S[T]()` create test slices.
Applied to files:
slices_test.gogenerics_test.gozero_test.go
📚 Learning: extensive use of go 1.23+ generics for type-safe utilities....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Applied to files:
generics_test.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*.go : cognitive complexity: 7....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cognitive complexity: 7.
Applied to files:
generics_test.gostack_test.gozero_test.goREADME.md
📚 Learning: in go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as ...
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.
Applied to files:
generics_test.gozero_test.goREADME.md
📚 Learning: applies to **/*.go : cyclomatic complexity: 10....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cyclomatic complexity: 10.
Applied to files:
stack_test.gopanic_test.goREADME.md
📚 Learning: in `list.go`, the `list[t]` methods `len` and `foreach` handle a nil receiver gracefully....
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.
Applied to files:
zero_test.go
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `README.md` to reflect significant changes in functionality or API.
Applied to files:
README.md
📚 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-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
README.md
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
README.md
📚 Learning: update documentation when adding new tools or changing workflows....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Update documentation when adding new tools or changing workflows.
Applied to files:
README.md
📚 Learning: in the darvaza.org/core module, the spinlock type is being deprecated in favor of darvaza.org/x/sync...
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.
Applied to files:
README.md
🧬 Code Graph Analysis (5)
errors_test.go (2)
testing.go (7)
TestCase(158-161)T(20-28)AssertEqual(187-196)RunTestCases(169-176)AssertTrue(345-348)S(149-154)AssertFalse(360-363)errors.go (11)
IsErrorFn(234-257)IsErrorFn2(265-291)Unwrap(181-206)CoalesceError(170-177)IsError(210-228)IsTemporary(341-344)IsTimeout(396-399)NewTimeoutError(152-157)NewTemporaryError(161-165)CheckIsTemporary(308-323)CheckIsTimeout(363-378)
testing_test.go (2)
testing.go (19)
TestCase(158-161)T(20-28)S(149-154)AssertSliceEqual(227-236)MockT(32-38)AssertEqual(187-196)AssertNotEqual(207-216)AssertContains(246-255)AssertError(265-268)AssertNoError(278-281)AssertNil(412-421)AssertNotNil(431-440)AssertErrorIs(374-383)AssertTypeIs(393-402)AssertPanic(292-309)AssertNoPanic(320-333)RunConcurrentTest(452-458)RunTestCases(169-176)RunBenchmark(470-477)compounderror.go (1)
Errors(10-13)
slices_test.go (3)
testing.go (6)
TestCase(158-161)T(20-28)AssertSliceEqual(227-236)S(149-154)RunTestCases(169-176)AssertEqual(187-196)slices.go (15)
SliceCopy(199-206)SliceReverse(307-314)SliceEqual(51-59)SliceUniqueFn(96-110)SliceSort(253-259)SliceCopyFn(180-196)SliceMinus(11-15)SliceMinusFn(20-30)SliceRandom(225-238)SliceContains(33-37)SliceMap(210-220)SliceReversed(317-321)SliceReversedFn(324-329)SliceSortFn(243-247)SliceSortOrdered(262-268)constraints.go (1)
Ordered(39-41)
stack_test.go (2)
testing.go (4)
TestCase(158-161)T(20-28)RunTestCases(169-176)AssertEqual(187-196)stack.go (3)
Stack(242-242)Frame(35-46)Here(296-305)
panic_test.go (4)
testing.go (13)
TestCase(158-161)T(20-28)AssertNil(412-421)AssertNotNil(431-440)AssertTypeIs(393-402)AssertEqual(187-196)RunTestCases(169-176)AssertError(265-268)AssertNoError(278-281)AssertTrue(345-348)AssertSliceEqual(227-236)S(149-154)AssertContains(246-255)zero.go (1)
IsNil(132-145)panicerror.go (2)
NewPanicError(45-53)PanicError(16-19)panic.go (8)
AsRecovered(15-28)Recovered(8-11)Catcher(31-33)Catch(78-81)Must(94-99)Maybe(115-117)MustOK(133-138)MaybeOK(154-156)
🪛 LanguageTool
README.md
[locale-violation] ~304-~304: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... value or panics with PanicError if ok is false. Useful for operations that sh...
(OK)
[locale-violation] ~306-~306: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... always returns the value, ignoring the ok flag. Useful when you want to proceed...
(OK)
[grammar] ~479-~479: This sentence seems to be incomplete. Insert a noun before ‘Is’ to make the sentence complete.
Context: ...t, msg...)- error chain checking with errors.Is. * AssertTypeIs[T](t, value, msg...)`...
(MISSING_SUBJECT)
[locale-violation] ~482-~482: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ...sertion with casting, returns (value, ok). * `AssertPanic(t, fn, expectedPanic, ...
(OK)
[style] ~488-~488: Would you like to use the Oxford spelling “standardized”? The spelling ‘standardised’ is also correct.
Context: ...ing Utilities * TestCase interface - standardised interface for table-driven tests with ...
(OXFORD_SPELLING_Z_NOT_S)
🔇 Additional comments (34)
errors_test.go (2)
9-19: LGTM! Comprehensive compile-time interface checks.Good practice to verify all test case types implement the TestCase interface at compile time.
50-68: LGTM! Excellent adoption of the new testing framework.The refactoring successfully implements all required testing patterns:
- TestCase interface implementation for all test types
- Factory functions for test case instantiation
- Consistent use of assertion helpers
- Generic RunTestCases for test execution
testing_test.go (2)
350-358: LGTM! Proper race condition fix using atomic operations.The use of
atomic.AddInt64andatomic.LoadInt64correctly addresses the race condition for concurrent counter access. This ensures thread-safe operation under race detection.
594-633: LGTM! Comprehensive concurrent testing of MockT.Excellent test design that exercises all MockT methods concurrently and verifies thread-safe operation. The deterministic operation counts based on worker ID modulo ensure predictable verification.
slices_test.go (2)
9-22: LGTM! Thorough compile-time interface verification.All test case types are properly verified to implement the TestCase interface at compile time.
50-609: LGTM! Successful adoption of standardised testing patterns.The refactoring comprehensively implements all required testing patterns:
- All test types implement TestCase interface with proper factory functions
- Consistent use of RunTestCases for test execution
- Proper use of assertion helpers throughout (except one minor case)
- Clean separation of concerns with helper functions
generics_test.go (5)
8-15: LGTM! Good use of compile-time interface validation.These compile-time checks ensure all test case types properly implement the TestCase interface, preventing runtime errors.
23-43: LGTM! Clean TestCase interface implementation.The methods correctly implement the TestCase interface, and the factory function follows a consistent pattern for test case creation.
45-60: LGTM! Comprehensive test coverage with clean syntax.Good use of the S() helper function for slice creation and comprehensive edge case coverage including empty inputs, negative values, and boundary conditions.
89-119: LGTM! Proper handling of pointer comparison logic.The implementation correctly preserves the special pointer comparison logic while adapting to the TestCase interface pattern.
400-427: LGTM! Clear verification of IIf evaluation semantics.The extracted helper functions clearly demonstrate that both branches are evaluated before IIf selection, which is important for understanding the function's behaviour.
stack_test.go (7)
10-20: LGTM! Comprehensive interface compliance checks.All test case types are validated to implement the TestCase interface at compile time.
90-177: LGTM! Excellent modularisation of stack trace validation.The refactoring introduces clear data structures and helper functions that make the stack trace validation logic much more maintainable and understandable. Good separation of concerns between analysis and validation.
178-214: LGTM! Clean implementation of SplitName test cases.Good use of Here() to test with actual runtime frames and proper helper function for assertion.
226-266: LGTM! Thorough testing including nil frame handling.Good edge case coverage with explicit handling of nil frame scenario.
319-324: LGTM! Consistent use of assertion helpers.
410-415: LGTM! Clean assertions for line number tests.
467-475: LGTM! Proper Stringer interface testing.Good validation that String() method matches the default formatting behaviour.
panic_test.go (8)
9-21: LGTM! Complete interface validation coverage.All panic-related test case types are properly validated to implement TestCase.
28-92: LGTM! Simplified and clear recovered value testing.Good use of IsNil for null checking and proper handling of string-to-error conversions that occur in NewPanicError.
391-428: LGTM! Well-designed test helper for Must function.The testMust helper elegantly captures panics for testing, and the struct field ordering follows memory alignment best practices.
436-477: LGTM! Excellent generic test helper design.Great use of generics to handle different types uniformly while maintaining type safety through the dispatcher pattern.
513-529: LGTM! Thorough panic validation.Excellent verification of error wrapping, type correctness, and stack trace capture.
597-609: LGTM! Consistent helper pattern for MustOK.
721-737: LGTM! Comprehensive MustOK panic validation.Good addition of error message content verification using AssertContains.
773-806: LGTM! Complete MaybeOK test coverage.Properly verifies that MaybeOK returns the value regardless of the boolean flag state.
zero_test.go (8)
10-17: LGTM! Complete interface validation for zero tests.
18-63: LGTM! Excellent generic test case design.Smart separation between value types (using comparable constraint) and reference types, with appropriate assertions for each.
65-140: LGTM! Comprehensive type coverage with clear organisation.Excellent use of subtests to organize tests by type category, with complete coverage of Go's type system.
187-232: LGTM! Exhaustive primitive type coverage.Excellent coverage of all Go primitive types including often-overlooked types like complex numbers and uintptr.
264-287: LGTM! Critical edge case coverage.Important distinction between nil (zero) and empty (non-zero) for slices and maps is properly tested.
472-554: LGTM! Excellent clarification of nil vs zero semantics.These comparison tests provide valuable documentation of the subtle but important differences between IsNil and IsZero, especially for slices and maps.
745-788: LGTM! Clear demonstration of initialization semantics.Excellent tests that show the practical use of IsZero for determining when initialization is needed.
790-834: LGTM! Valuable practical examples.These examples effectively demonstrate real-world lazy initialization patterns using IsZero, providing clear guidance for library users.
|
@coderabbitai Applied your feedback: replaced direct |
|
Tip For best results, initiate chat on the files or code changes. @amery Thank you for implementing that feedback! Replacing the direct The use of 🧠 Learnings used |
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
slices_test.go (1)
365-367: Use assertion helper for consistency.Replace direct
t.Errorfcall withAssertEqualto maintain consistency with the testing patterns used throughout the file.result := SliceMap(S[int](), intToString) - if len(result) != 0 { - t.Errorf("Expected empty slice, got %v", result) - } + AssertEqual(t, 0, len(result), "SliceMap empty slice length")
🧹 Nitpick comments (2)
README.md (1)
304-304: Use British English 'OK' instead of lowercase 'ok'.In British English, the correct spelling is 'OK' rather than lowercase 'ok'.
-* `MustOK[T](value T, ok bool) T` - returns value or panics with `PanicError` if - ok is false. Useful for operations that should always succeed, such as map +* `MustOK[T](value T, ok bool) T` - returns value or panics with `PanicError` if + OK is false. Useful for operations that should always succeed, such as map-* `MaybeOK[T](value T, ok bool) T` - always returns the value, ignoring the ok +* `MaybeOK[T](value T, ok bool) T` - always returns the value, ignoring the OK- (value, ok). + (value, OK).Also applies to: 306-306, 482-482
zero_test.go (1)
65-70: Consider removing redundant wrapper function.The
testZeroTfunction only wrapsRunTestCaseswithout adding functionality. Consider callingRunTestCasesdirectly in the tests.-// testZeroT tests Zero function for reference types that should return nil -func testZeroT[T any](t *testing.T, testCases ...zeroRefTestCase[T]) { - t.Helper() - - RunTestCases(t, testCases) -}Then update the test calls:
-t.Run("slice", func(t *testing.T) { testZeroT(t, zeroSliceTestCases...) }) +t.Run("slice", func(t *testing.T) { RunTestCases(t, zeroSliceTestCases) })
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (22)
README.md(3 hunks)addrport_test.go(6 hunks)addrs_test.go(10 hunks)as_test.go(11 hunks)compounderror_test.go(10 hunks)context_test.go(10 hunks)errgroup_test.go(5 hunks)errors_test.go(21 hunks)generics_test.go(14 hunks)internal/build/cspell.json(2 hunks)lists_test.go(8 hunks)maps_test.go(27 hunks)panic.go(1 hunks)panic_test.go(5 hunks)panicerror_test.go(10 hunks)slices_test.go(11 hunks)spinlock_test.go(5 hunks)splithostport_test.go(17 hunks)stack_test.go(20 hunks)testing_test.go(1 hunks)waitgroup_test.go(6 hunks)zero_test.go(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (15)
- internal/build/cspell.json
- context_test.go
- waitgroup_test.go
- panic.go
- spinlock_test.go
- lists_test.go
- addrport_test.go
- splithostport_test.go
- errors_test.go
- compounderror_test.go
- generics_test.go
- errgroup_test.go
- as_test.go
- panicerror_test.go
- maps_test.go
🧰 Additional context used
📓 Path-based instructions (5)
**/*.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.go: Enforce strict linting rules via revive with configuration ininternal/build/revive.toml.
Max function length: 40 lines.
Max function results: 3.
Max arguments: 5.
Cognitive complexity: 7.
Cyclomatic complexity: 10.
Field alignment optimization for struct definitions using thefieldalignmenttool.
Files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.go
**/*_test.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*_test.go: Use test helper functions defined intestutils_test.goto reduce boilerplate and improve test consistency.
UseAssertEqual[T](t, expected, actual, msg...)for generic value comparison in tests.
UseAssertSliceEqual[T](t, expected, actual, msg...)for slice comparison in tests.
UseAssertError(t, err, expectError, msg...)for standardized error expectation checking in tests.
UseAssertBool(t, actual, expected, msg...)for boolean assertions in tests.
UseAssertPanic(t, fn, expectedPanic, msg...)for simplified panic testing in tests.
UseAssertNoPanic(t, fn, msg...)to ensure functions don't panic in tests.
UseRunConcurrentTest(t, numWorkers, workerFn)for concurrent testing with goroutines.
UseRunBenchmark(b, setupFn, execFn)for benchmark testing with setup/execution phases.
UseRunTestCases(t, []TestCase)for table-driven test runners.
Files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.go
**/*
📄 CodeRabbit Inference Engine (AGENT.md)
**/*: Remove trailing whitespace from all text files.
Ensure files end with a newline.
Files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.goREADME.md
**/*.{md,go}
📄 CodeRabbit Inference Engine (AGENT.md)
Check spelling in both Markdown and Go source files using CSpell with configuration in
internal/build/cspell.json.
Files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.goREADME.md
**/*.md
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.md: Run Markdownlint on Markdown files with configuration ininternal/build/markdownlint.json.
Enforce 80-character line limits and strict formatting rules in Markdown files.
Allow only a selective HTML allowlist (comments, br, kbd, etc.) in Markdown files.
Run LanguageTool grammar and style checking on Markdown files using British English configuration ininternal/build/languagetool.cfg.
Markdown files must comply with LanguageTool (grammar), CSpell (spelling), and Markdownlint (formatting) standards.
End all bullet points in Markdown files with periods for consistency.
Capitalize proper nouns correctly (JavaScript, TypeScript, Markdown) in Markdown files.
Use consistent punctuation in examples and lists in Markdown files.
Files:
README.md
🧠 Learnings (23)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
📚 Learning: applies to **/*_test.go : use test helper functions defined in `testutils_test.go` to reduce boilerp...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Applied to files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertequal[t](t, expected, actual, msg...)` for generic value compar...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Applied to files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertsliceequal[t](t, expected, actual, msg...)` for slice compariso...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Applied to files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `asserterror(t, err, expecterror, msg...)` for standardized error expe...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Applied to files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertpanic(t, fn, expectedpanic, msg...)` for simplified panic testi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Applied to files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertbool(t, actual, expected, msg...)` for boolean assertions in te...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Applied to files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertnopanic(t, fn, msg...)` to ensure functions don't panic in test...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Applied to files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runtestcases(t, []testcase)` for table-driven test runners....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Applied to files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runconcurrenttest(t, numworkers, workerfn)` for concurrent testing wi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
Applied to files:
testing_test.goslices_test.goaddrs_test.gostack_test.gozero_test.gopanic_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runbenchmark(b, setupfn, execfn)` for benchmark testing with setup/ex...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunBenchmark(b, setupFn, execFn)` for benchmark testing with setup/execution phases.
Applied to files:
testing_test.goslices_test.goaddrs_test.gostack_test.go
📚 Learning: helper functions like `s[t]()` create test slices....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Helper functions like `S[T]()` create test slices.
Applied to files:
slices_test.gozero_test.go
📚 Learning: applies to **/*.go : cognitive complexity: 7....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cognitive complexity: 7.
Applied to files:
slices_test.goaddrs_test.gostack_test.gozero_test.goREADME.md
📚 Learning: applies to **/*.go : cyclomatic complexity: 10....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cyclomatic complexity: 10.
Applied to files:
addrs_test.gostack_test.gopanic_test.goREADME.md
📚 Learning: extensive use of go 1.23+ generics for type-safe utilities....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Applied to files:
zero_test.gopanic_test.goREADME.md
📚 Learning: in `list.go`, the `list[t]` methods `len` and `foreach` handle a nil receiver gracefully....
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.
Applied to files:
zero_test.go
📚 Learning: in go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as ...
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.
Applied to files:
zero_test.goREADME.md
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `README.md` to reflect significant changes in functionality or API.
Applied to files:
README.md
📚 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-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
README.md
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
README.md
📚 Learning: update documentation when adding new tools or changing workflows....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Update documentation when adding new tools or changing workflows.
Applied to files:
README.md
📚 Learning: `errnilreceiver`, defined in `errors.go`, is intended for use by other packages even if it's not use...
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.
Applied to files:
README.md
📚 Learning: in the darvaza.org/core module, the spinlock type is being deprecated in favor of darvaza.org/x/sync...
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.
Applied to files:
README.md
🧬 Code Graph Analysis (1)
testing_test.go (2)
testing.go (19)
TestCase(158-161)T(20-28)S(149-154)AssertSliceEqual(227-236)MockT(32-38)AssertEqual(187-196)AssertNotEqual(207-216)AssertContains(246-255)AssertError(265-268)AssertNoError(278-281)AssertNil(412-421)AssertNotNil(431-440)AssertErrorIs(374-383)AssertTypeIs(393-402)AssertPanic(292-309)AssertNoPanic(320-333)RunConcurrentTest(452-458)RunTestCases(169-176)RunBenchmark(470-477)compounderror.go (1)
Errors(10-13)
🪛 LanguageTool
README.md
[locale-violation] ~304-~304: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... value or panics with PanicError if ok is false. Useful for operations that sh...
(OK)
[locale-violation] ~306-~306: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... always returns the value, ignoring the ok flag. Useful when you want to proceed...
(OK)
[grammar] ~479-~479: This sentence seems to be incomplete. Insert a noun before ‘Is’ to make the sentence complete.
Context: ...t, msg...)- error chain checking with errors.Is. * AssertTypeIs[T](t, value, msg...)`...
(MISSING_SUBJECT)
[locale-violation] ~482-~482: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ...sertion with casting, returns (value, ok). * `AssertPanic(t, fn, expectedPanic, ...
(OK)
[style] ~488-~488: Would you like to use the Oxford spelling “standardized”? The spelling ‘standardised’ is also correct.
Context: ...ing Utilities * TestCase interface - standardised interface for table-driven tests with ...
(OXFORD_SPELLING_Z_NOT_S)
🔇 Additional comments (19)
testing_test.go (1)
1-634: Well-structured and comprehensive test coverage!The test file excellently covers all aspects of the new testing utilities:
- Thorough MockT implementation testing with concurrent safety
- Complete coverage of all assertion functions
- Proper use of atomic operations in concurrent tests
- Good test organisation with helper functions
The implementation follows all the testing patterns and best practices outlined in the PR.
addrs_test.go (1)
10-550: Excellent refactoring to align with new testing patterns!The test file has been successfully refactored to:
- Implement the TestCase interface for all test types
- Use factory functions consistently for test case creation
- Extract complex test logic into named helper functions
- Maintain the same test coverage while improving organisation
This aligns perfectly with the testing guidelines established in this PR.
stack_test.go (1)
84-176: Excellent modularisation of complex test logic!The refactoring of
TestStackTraceinto smaller, focused functions is a significant improvement:
- Clear separation of concerns with
stackTraceExpectation,stackAnalysisstructs- Well-named helper functions that each handle a specific aspect of validation
- Improved readability and maintainability
- Adheres to cognitive complexity guidelines
This is a model example of how to refactor complex test functions.
zero_test.go (9)
10-17: Good use of compile-time interface verification.The compile-time checks ensure all test case types properly implement the
TestCaseinterface, preventing runtime errors.
18-32: Well-structured generic test case implementation.The
zeroTestCase[T comparable]type properly implements theTestCaseinterface with appropriate use of generics and helper methods.
72-120: Excellent consistency with testing patterns.The test cases consistently use the
S()helper function and constructor patterns, aligning with the established testing guidelines.
122-134: Good test organisation with subtests.The test structure properly organises test cases by type using
t.Run. The approach ensures clear test output and proper isolation.
162-177: Clean test case implementation for IsZero.The
isZeroTestCaseproperly implements theTestCaseinterface with clear field names and appropriate assertions.
187-232: Comprehensive type coverage for IsZero tests.Excellent coverage of all Go numeric types including signed/unsigned integers, floating-point, complex numbers, and special types like rune and uintptr.
234-261: Thorough testing of interface edge cases.Good coverage of interface scenarios, correctly distinguishing between nil interfaces, interfaces containing nil, and interfaces containing zero values. The comment clarifying that empty slices are not zero values is particularly helpful.
715-788: Excellent documentation of initialization semantics.The
initializationSemanticsTestCasetests provide valuable documentation of whenIsZeroreturns true (indicating need for initialization) vs false (already initialized). This is particularly useful for understanding nil vs empty distinctions in Go.
790-834: Valuable practical examples of IsZero usage.These tests effectively demonstrate real-world lazy initialization patterns using
IsZero. They serve as both functional tests and practical documentation for users of the API.panic_test.go (7)
9-21: Comprehensive compile-time interface verification.All test case types are properly verified to implement the
TestCaseinterface, ensuring type safety.
22-92: Well-refactored test case with improved edge case handling.The refactored
asRecoveredTestCaseeffectively usesIsNilviaMustNil()method and properly handles the edge case where string panics are converted to errors byNewPanicError.
391-403: Elegant helper for testing panic scenarios.The
testMusthelper effectively wrapsMustcalls with panic recovery, enabling comprehensive testing of both success and panic scenarios.
405-490: Well-structured success test cases for Must function.The implementation provides good type coverage with dedicated generic helpers for comparable types and slices. The type switch pattern effectively handles different value types.
492-539: Thorough panic scenario testing with proper error verification.The test properly verifies that
Mustpanics with aPanicErrorcontaining the original error and a stack trace. Good use oferrors.Isto verify error wrapping.
541-595: Clean implementation of Maybe function tests.The tests effectively verify that
Maybealways returns the input value regardless of error presence, which is the expected behaviour.
597-806: Consistent and comprehensive MustOK/MaybeOK test implementation.The tests follow the established patterns from Must/Maybe tests, providing thorough coverage of success and panic scenarios. Good attention to verifying panic message content.
|
|
||
| * `AssertError(t, err, msg...)` / `AssertNoError(t, err, msg...)` - error | ||
| presence/absence. | ||
| * `AssertErrorIs(t, err, target, msg...)` - error chain checking with |
There was a problem hiding this comment.
Fix grammar: add missing subject before 'Is'.
The sentence is incomplete and needs a subject before 'Is'.
- * panic testing with `errors.Is`.
+ * panic testing.Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 LanguageTool
[grammar] ~479-~479: This sentence seems to be incomplete. Insert a noun before ‘Is’ to make the sentence complete.
Context: ...t, msg...)- error chain checking with errors.Is. * AssertTypeIs[T](t, value, msg...)`...
(MISSING_SUBJECT)
🤖 Prompt for AI Agents
In README.md at line 479, the phrase "`AssertErrorIs(t, err, target, msg...)` -
error chain checking with" is incomplete and missing a subject before "Is". Add
a subject such as "function" or "method" before "Is" to complete the sentence
and clarify that AssertErrorIs is a function performing error chain checking.
There was a problem hiding this comment.
this is fixed now, please confirm
There was a problem hiding this comment.
🧩 Analysis chain
@amery Looking at the current content of README.md around line 479, I can confirm that the grammar issue has been fixed!
The line now reads:
* `AssertErrorIs(t, err, target, msg...)` - error chain checking with `errors.Is`.
This is a complete and grammatically correct sentence. The previous issue where the sentence seemed incomplete has been resolved. The description now clearly explains that AssertErrorIs performs error chain checking using the errors.Is function.
🏁 Script executed:
#!/bin/bash
# Check the current content around line 479 in README.md to verify the grammar fix
sed -n '475,485p' README.md | cat -n
Length of output: 515
@amery Yes, I can confirm the grammar issue has been fixed!
Looking at the current content, the line now correctly reads:
* `AssertErrorIs(t, err, target, msg...)` - error chain checking with
`errors.Is`.
This is a complete and grammatically correct sentence. The description clearly explains that AssertErrorIs performs error chain checking using the errors.Is function from Go's standard library. The previous concern about an incomplete sentence has been resolved.
Thank you for the correction!
🧠 Learnings used
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: 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-18T16:39:19.390Z
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-30T02:57:51.092Z
Learning: 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-30T02:57:51.092Z
Learning: Update documentation when adding new tools or changing workflows.
Add organisation-wide testing documentation to establish consistent patterns across all darvaza.org projects and provide detailed guidance for the new public testing API. - **TESTING.md** (628 lines): General testing guidelines for all darvaza.org projects with assertion hierarchy, MockT patterns, and reusability principles. - **TESTING_core.md** (525 lines): Core-specific testing patterns focusing on self-testing approaches and zero-dependency testing methodologies. - **AGENT.md**: Remove detailed testing documentation (120 lines) now covered by dedicated TESTING files, add references to new documentation. - **README.md**: Add Testing Utilities section references pointing to new comprehensive testing documentation. The documentation establishes: - **Assertion hierarchy**: Clear dependency chain with AssertEqual as base, AssertTrue/AssertFalse as derived functions. - **Testing patterns**: Table-driven tests, MockT usage, circular dependency avoidance, and self-testing methodologies. - **Organisation standards**: Consistent testing approaches across all darvaza.org projects with external reusability principles. - **Best practices**: Generic function testing, error handling patterns, concurrent testing guidelines, and benchmark management. This documentation complements the public testing API by providing detailed guidance on proper usage patterns and establishing testing standards for the entire darvaza.org ecosystem. Files changed: 4 files, +1171/-120 lines Signed-off-by: Alejandro Mery <amery@apply.co>
Add `AssertNotEqual` as a base assertion function with standalone implementation following the established pattern. This complements `AssertEqual` by providing direct inequality testing with consistent error messaging and logging behaviour. - **`AssertNotEqual[T]`**: Generic function using `!=` comparison with `"expected not %v, got %v"` error format. - **`TestAssertNotEqual`**: Comprehensive test coverage for both success and failure cases using `MockT`. - **Documentation**: Updated assertion hierarchy in `TESTING_core.md`, basic assertions list in `TESTING.md`, and function count in `README.md`. The function is positioned as a base function in the hierarchy rather than derived from `AssertEqual`, ensuring independent implementation and consistent behaviour across the testing utilities. Signed-off-by: Alejandro Mery <amery@apply.co>
Convert all test files to use the public TestCase interface with consistent patterns and improved maintainability. **TestCase Interface Implementation:** - Add TestCase interface validations for all test case types. - Convert struct test cases to implement Name() and Test() methods. - Replace manual test loops with RunTestCases() helper function. - Add factory functions for all test case struct constructors. **Assertion Function Migration:** - Replace manual error checking with AssertError/AssertNoError. - Replace manual nil checks with AssertNil/AssertNotNil. - Replace manual boolean checks with AssertTrue/AssertFalse. - Replace reflect.DeepEqual with AssertEqual/AssertSliceEqual. - Replace manual type assertions with AssertTypeIs. - Replace manual panic testing with AssertPanic/AssertNoPanic. - Use SliceContains utility for slice membership testing. **Test Data Modernisation:** - Replace naked struct literals with factory function calls. - Extract complex anonymous functions to named helper methods. - Implement consistent test case constructor patterns. **Code Quality Enhancements:** - Add compile-time TestCase interface verification. - Break down high-complexity functions into smaller helpers. - Replace formatter usage with proper Frame methods in validation logic. **Updated Documentation:** - Add testing-related terms to cspell.json dictionary. - Maintain consistent terminology across test files. This refactoring establishes uniform TestCase patterns across 19 test files whilst maintaining 96.9% test coverage and zero linting issues. Signed-off-by: Alejandro Mery <amery@apply.co>
Add Must[T] and Maybe[T] generic functions following common Go patterns: - Must[T](value T, err error) T - panics with PanicError if err \!= nil, returns value unchanged if err == nil. Useful for tests, config loading, and cases where errors should never occur. - Maybe[T](value T, err error) T - always returns value, ignoring error. Useful when proceeding with defaults/zero values regardless of errors. Both functions work with any type T and include comprehensive test coverage using TESTING.md compliant patterns with named test types, constructor functions, and generic test helpers. Also updates README.md with documentation and examples, and adds required words to cspell dictionary. Signed-off-by: Alejandro Mery <amery@apply.co>
Add MustOK() and MaybeOK() functions following the same patterns as the existing Must() and Maybe() utilities. These functions handle operations that return (value, bool) pairs instead of (value, error) pairs. * MustOK[V any](value V, ok bool) V - panics with PanicError if ok is false. * MaybeOK[V any](value V, ok bool) V - returns value ignoring ok flag. * Comprehensive test coverage with TestCase interface compliance. * Updated documentation with usage examples using MapValue() and As(). These utilities are useful for operations like map access, type assertions, and other Go idioms that return boolean success indicators. Signed-off-by: Alejandro Mery <amery@apply.co>
PR Branch UpdatesMinor cleanup and consistency improvements applied to the branch: Changes Made
FYI @karasz, @coderabbitai |
|
Tip For best results, initiate chat on the files or code changes. @amery Thank you for the updates! These cleanup and consistency improvements are excellent and align perfectly with the established standards: ✅ Go 1.23 requirement update - Matches the minimum version requirement from the learnings These incremental improvements demonstrate excellent attention to detail and commitment to code quality. The changes reinforce the testing infrastructure transformation goals while maintaining the high standards established throughout this PR. 🐰 🧠 Learnings used |
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
README.md (2)
293-327: Line length violations and British English compliance issues.This is a duplicate of previously identified issues. Several lines exceed the 80-character limit and use American English "ok" instead of British English "OK".
438-505: Line length violations and grammar issue.This section has the same issues previously identified: multiple lines exceed the 80-character limit, and line 479 has an incomplete sentence that needs a subject before "Is".
slices_test.go (1)
359-366: Past review comment successfully addressed.The code now uses
AssertEqualassertion helper instead of directt.Errorfcall, maintaining consistency with the testing patterns used throughout the file.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (26)
AGENT.md(3 hunks)README.md(4 hunks)TESTING.md(1 hunks)TESTING_core.md(1 hunks)addrport_test.go(6 hunks)addrs_test.go(10 hunks)as_test.go(11 hunks)compounderror_test.go(10 hunks)context_test.go(10 hunks)errgroup_test.go(5 hunks)errors_test.go(21 hunks)generics_test.go(14 hunks)internal/build/cspell.json(2 hunks)lists_test.go(8 hunks)maps_test.go(27 hunks)panic.go(1 hunks)panic_test.go(5 hunks)panicerror_test.go(10 hunks)slices_test.go(11 hunks)spinlock_test.go(5 hunks)splithostport_test.go(17 hunks)stack_test.go(20 hunks)testing.go(1 hunks)testing_test.go(1 hunks)waitgroup_test.go(6 hunks)zero_test.go(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (16)
- internal/build/cspell.json
- AGENT.md
- splithostport_test.go
- addrport_test.go
- waitgroup_test.go
- panic.go
- compounderror_test.go
- context_test.go
- addrs_test.go
- spinlock_test.go
- as_test.go
- errors_test.go
- stack_test.go
- lists_test.go
- errgroup_test.go
- maps_test.go
🧰 Additional context used
📓 Path-based instructions (5)
**/*.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.go: Enforce strict linting rules via revive with configuration ininternal/build/revive.toml.
Max function length: 40 lines.
Max function results: 3.
Max arguments: 5.
Cognitive complexity: 7.
Cyclomatic complexity: 10.
Field alignment optimization for struct definitions using thefieldalignmenttool.
Files:
slices_test.gotesting_test.gopanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.go
**/*_test.go
📄 CodeRabbit Inference Engine (AGENT.md)
**/*_test.go: Use test helper functions defined intestutils_test.goto reduce boilerplate and improve test consistency.
UseAssertEqual[T](t, expected, actual, msg...)for generic value comparison in tests.
UseAssertSliceEqual[T](t, expected, actual, msg...)for slice comparison in tests.
UseAssertError(t, err, expectError, msg...)for standardized error expectation checking in tests.
UseAssertBool(t, actual, expected, msg...)for boolean assertions in tests.
UseAssertPanic(t, fn, expectedPanic, msg...)for simplified panic testing in tests.
UseAssertNoPanic(t, fn, msg...)to ensure functions don't panic in tests.
UseRunConcurrentTest(t, numWorkers, workerFn)for concurrent testing with goroutines.
UseRunBenchmark(b, setupFn, execFn)for benchmark testing with setup/execution phases.
UseRunTestCases(t, []TestCase)for table-driven test runners.
Files:
slices_test.gotesting_test.gopanicerror_test.gogenerics_test.gopanic_test.gozero_test.go
**/*
📄 CodeRabbit Inference Engine (AGENT.md)
**/*: Remove trailing whitespace from all text files.
Ensure files end with a newline.
Files:
slices_test.goTESTING_core.mdtesting_test.goTESTING.mdpanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
**/*.{md,go}
📄 CodeRabbit Inference Engine (AGENT.md)
Check spelling in both Markdown and Go source files using CSpell with configuration in
internal/build/cspell.json.
Files:
slices_test.goTESTING_core.mdtesting_test.goTESTING.mdpanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
**/*.md
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.md: Run Markdownlint on Markdown files with configuration ininternal/build/markdownlint.json.
Enforce 80-character line limits and strict formatting rules in Markdown files.
Allow only a selective HTML allowlist (comments, br, kbd, etc.) in Markdown files.
Run LanguageTool grammar and style checking on Markdown files using British English configuration ininternal/build/languagetool.cfg.
Markdown files must comply with LanguageTool (grammar), CSpell (spelling), and Markdownlint (formatting) standards.
End all bullet points in Markdown files with periods for consistency.
Capitalize proper nouns correctly (JavaScript, TypeScript, Markdown) in Markdown files.
Use consistent punctuation in examples and lists in Markdown files.
Files:
TESTING_core.mdTESTING.mdREADME.md
🧠 Learnings (36)
📓 Common learnings
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
📚 Learning: applies to **/*_test.go : use `assertsliceequal[t](t, expected, actual, msg...)` for slice compariso...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertSliceEqual[T](t, expected, actual, msg...)` for slice comparison in tests.
Applied to files:
slices_test.goTESTING_core.mdtesting_test.goTESTING.mdpanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runtestcases(t, []testcase)` for table-driven test runners....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunTestCases(t, []TestCase)` for table-driven test runners.
Applied to files:
slices_test.goTESTING_core.mdtesting_test.goTESTING.mdpanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use test helper functions defined in `testutils_test.go` to reduce boilerp...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use test helper functions defined in `testutils_test.go` to reduce boilerplate and improve test consistency.
Applied to files:
slices_test.goTESTING_core.mdtesting_test.goTESTING.mdpanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: helper functions like `s[t]()` create test slices....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Helper functions like `S[T]()` create test slices.
Applied to files:
slices_test.gogenerics_test.gozero_test.go
📚 Learning: applies to **/*_test.go : use `assertequal[t](t, expected, actual, msg...)` for generic value compar...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertEqual[T](t, expected, actual, msg...)` for generic value comparison in tests.
Applied to files:
slices_test.goTESTING_core.mdtesting_test.goTESTING.mdpanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `asserterror(t, err, expecterror, msg...)` for standardized error expe...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertError(t, err, expectError, msg...)` for standardized error expectation checking in tests.
Applied to files:
slices_test.goTESTING_core.mdtesting_test.goTESTING.mdpanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertpanic(t, fn, expectedpanic, msg...)` for simplified panic testi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertPanic(t, fn, expectedPanic, msg...)` for simplified panic testing in tests.
Applied to files:
slices_test.goTESTING_core.mdtesting_test.goTESTING.mdpanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runbenchmark(b, setupfn, execfn)` for benchmark testing with setup/ex...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunBenchmark(b, setupFn, execFn)` for benchmark testing with setup/execution phases.
Applied to files:
slices_test.gotesting_test.goTESTING.mdpanicerror_test.gotesting.go
📚 Learning: applies to **/*_test.go : use `assertnopanic(t, fn, msg...)` to ensure functions don't panic in test...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertNoPanic(t, fn, msg...)` to ensure functions don't panic in tests.
Applied to files:
slices_test.goTESTING_core.mdtesting_test.goTESTING.mdpanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `assertbool(t, actual, expected, msg...)` for boolean assertions in te...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `AssertBool(t, actual, expected, msg...)` for boolean assertions in tests.
Applied to files:
slices_test.goTESTING_core.mdtesting_test.goTESTING.mdpanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: applies to **/*.go : cognitive complexity: 7....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cognitive complexity: 7.
Applied to files:
slices_test.goTESTING_core.mdpanicerror_test.gozero_test.goREADME.md
📚 Learning: applies to **/*_test.go : use `runconcurrenttest(t, numworkers, workerfn)` for concurrent testing wi...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*_test.go : Use `RunConcurrentTest(t, numWorkers, workerFn)` for concurrent testing with goroutines.
Applied to files:
slices_test.gotesting_test.goTESTING.mdpanicerror_test.gogenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `README.md` to reflect significant changes in functionality or API.
Applied to files:
TESTING_core.mdTESTING.mdREADME.md
📚 Learning: applies to **/*.go : everything is in the `core` package, no subpackages....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: Applies to **/*.go : Everything is in the `core` package, no subpackages.
Applied to files:
TESTING_core.mdREADME.md
📚 Learning: applies to **/*.go : cyclomatic complexity: 10....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Cyclomatic complexity: 10.
Applied to files:
TESTING_core.mdpanicerror_test.gopanic_test.goREADME.md
📚 Learning: extensive use of go 1.23+ generics for type-safe utilities....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Extensive use of Go 1.23+ generics for type-safe utilities.
Applied to files:
TESTING_core.mdgenerics_test.gotesting.gopanic_test.gozero_test.goREADME.md
📚 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-18T16:39:19.390Z
Learning: Applies to AGENT.md : Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
TESTING.mdREADME.md
📚 Learning: 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-30T02:57:51.092Z
Learning: Update `AGENT.md` to reflect any changes in development workflow or standards.
Applied to files:
TESTING.mdREADME.md
📚 Learning: table-driven tests are preferred....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Table-driven tests are preferred.
Applied to files:
TESTING.md
📚 Learning: verify all tests pass with `make test` before committing....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Verify all tests pass with `make test` before committing.
Applied to files:
TESTING.md
📚 Learning: in go, avoid suggesting dereferencing a `nil` pointer receiver within a method to initialize it, as ...
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.
Applied to files:
generics_test.gozero_test.goREADME.md
📚 Learning: in `list.go`, the `list[t]` methods `len` and `foreach` handle a nil receiver gracefully....
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.
Applied to files:
zero_test.go
📚 Learning: update documentation when adding new tools or changing workflows....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Update documentation when adding new tools or changing workflows.
Applied to files:
README.md
📚 Learning: applies to **/*.md : enforce 80-character line limits and strict formatting rules in markdown files....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.md : Enforce 80-character line limits and strict formatting rules in Markdown files.
Applied to files:
README.md
📚 Learning: applies to **/*.go : max function length: 40 lines....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.go : Max function length: 40 lines.
Applied to files:
README.md
📚 Learning: applies to **/*.md : markdown files must comply with markdownlint rules (80-character line limits, s...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: Applies to **/*.md : Markdown files must comply with markdownlint rules (80-character line limits, strict formatting, selective HTML allowlist).
Applied to files:
README.md
📚 Learning: always run `make tidy` first before committing: fix all issues (go formatting, whitespace, cspell, m...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-18T16:39:19.390Z
Learning: ALWAYS run `make tidy` first before committing: fix all issues (Go formatting, whitespace, CSpell, markdownlint, shellcheck).
Applied to files:
README.md
📚 Learning: always run `make tidy` first before committing to fix all issues (go formatting, whitespace, markdow...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: ALWAYS run `make tidy` first before committing to fix all issues (Go formatting, whitespace, Markdown CSpell/markdownlint, shellcheck).
Applied to files:
README.md
📚 Learning: applies to **/*.md : use consistent punctuation in examples and lists in markdown files....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.md : Use consistent punctuation in examples and lists in Markdown files.
Applied to files:
README.md
📚 Learning: applies to **/*.md : markdown files must comply with languagetool (grammar), cspell (spelling), and ...
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Applies to **/*.md : Markdown files must comply with LanguageTool (grammar), CSpell (spelling), and Markdownlint (formatting) standards.
Applied to files:
README.md
📚 Learning: use only the go standard library and minimal golang.org/x packages (zero dependencies)....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Use only the Go standard library and minimal golang.org/x packages (zero dependencies).
Applied to files:
README.md
📚 Learning: in the darvaza-proxy/core monorepo coverage system, each .prof coverage file is generated from a dif...
Learnt from: amery
PR: darvaza-proxy/core#113
File: internal/build/make_coverage.sh:90-93
Timestamp: 2025-07-14T17:26:02.593Z
Learning: In the darvaza-proxy/core monorepo coverage system, each .prof coverage file is generated from a different Go module, so simple concatenation of coverage files is appropriate and won't cause duplicate package lines since each module covers its own distinct set of packages.
Applied to files:
README.md
📚 Learning: in the darvaza.org/core module, the spinlock type is being deprecated in favor of darvaza.org/x/sync...
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.
Applied to files:
README.md
📚 Learning: `errnilreceiver`, defined in `errors.go`, is intended for use by other packages even if it's not use...
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.
Applied to files:
README.md
📚 Learning: everything is in the `core` package, no subpackages....
Learnt from: CR
PR: darvaza-proxy/core#0
File: AGENT.md:0-0
Timestamp: 2025-07-30T02:57:51.092Z
Learning: Everything is in the `core` package, no subpackages.
Applied to files:
README.md
🧬 Code Graph Analysis (3)
testing_test.go (2)
testing.go (19)
TestCase(158-161)T(20-28)S(149-154)AssertSliceEqual(227-236)MockT(32-38)AssertEqual(187-196)AssertNotEqual(207-216)AssertContains(246-255)AssertError(265-268)AssertNoError(278-281)AssertNil(412-421)AssertNotNil(431-440)AssertErrorIs(374-383)AssertTypeIs(393-402)AssertPanic(292-309)AssertNoPanic(320-333)RunConcurrentTest(452-458)RunTestCases(169-176)RunBenchmark(470-477)compounderror.go (1)
Errors(10-13)
generics_test.go (1)
testing.go (4)
TestCase(158-161)T(20-28)S(149-154)RunTestCases(169-176)
panic_test.go (4)
testing.go (12)
TestCase(158-161)T(20-28)AssertNil(412-421)AssertNotNil(431-440)AssertEqual(187-196)RunTestCases(169-176)AssertError(265-268)AssertNoError(278-281)AssertTrue(345-348)AssertSliceEqual(227-236)S(149-154)AssertContains(246-255)zero.go (1)
IsNil(132-145)panicerror.go (2)
NewPanicError(45-53)PanicError(16-19)panic.go (8)
AsRecovered(15-28)Recovered(8-11)Catcher(31-33)Catch(78-81)Must(94-99)Maybe(115-117)MustOK(133-138)MaybeOK(154-156)
🪛 LanguageTool
TESTING.md
[style] ~52-~52: Would you like to use the Oxford spelling “standardized”? The spelling ‘standardised’ is also correct.
Context: ...and generic RunTestCases function for standardised table-driven tests: ```go // TestCase ...
(OXFORD_SPELLING_Z_NOT_S)
[style] ~507-~507: Would you like to use the Oxford spelling “specialized”? The spelling ‘specialised’ is also correct.
Context: ...ty and improve readability by providing specialised factory functions that match common usa...
(OXFORD_SPELLING_Z_NOT_S)
[uncategorized] ~508-~508: Possible missing comma found.
Context: ...ctory functions that match common usage patterns rather than forcing all callers to prov...
(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~728-~728: Would you like to use the Oxford spelling “centralized”? The spelling ‘centralised’ is also correct.
Context: ...inability**: Complex test data logic is centralised. 4. Readability: Test functions foc...
(OXFORD_SPELLING_Z_NOT_S)
[uncategorized] ~730-~730: Do not mix variants of the same word (‘parameterisation’ and ‘parameterization’) within a single text.
Context: ...ocus on execution, not data setup. 5. Parameterisation: Easy to create variations of test su...
(EN_WORD_COHERENCY)
[grammar] ~925-~925: Consider using “to” with “prefer”.
Context: ...t.Helper() in all helper functions. - Prefer table-driven tests over individual test functions. - Keep setup and clean-...
(PREFER_OVER_TO)
README.md
[locale-violation] ~304-~304: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... value or panics with PanicError if ok is false. Useful for operations that sh...
(OK)
[locale-violation] ~306-~306: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... always returns the value, ignoring the ok flag. Useful when you want to proceed...
(OK)
[grammar] ~479-~479: This sentence seems to be incomplete. Insert a noun before ‘Is’ to make the sentence complete.
Context: ...t, msg...)- error chain checking with errors.Is. * AssertTypeIs[T](t, value, msg...)`...
(MISSING_SUBJECT)
[locale-violation] ~482-~482: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ...sertion with casting, returns (value, ok). * `AssertPanic(t, fn, expectedPanic, ...
(OK)
[style] ~488-~488: Would you like to use the Oxford spelling “standardized”? The spelling ‘standardised’ is also correct.
Context: ...ing Utilities * TestCase interface - standardised interface for table-driven tests with ...
(OXFORD_SPELLING_Z_NOT_S)
🔇 Additional comments (38)
README.md (1)
535-551: Well-structured development section.The development section is well-organised with clear quick start commands and appropriate references to the AGENT.md file. The content is concise and follows Markdown formatting standards.
TESTING_core.md (6)
10-108: Excellent technical documentation on assertion hierarchy.This section provides clear, actionable guidance on testing assertion functions whilst avoiding circular dependencies. The hierarchy diagram and examples effectively demonstrate safe testing patterns.
109-302: Comprehensive testing patterns with excellent examples.The section provides thorough coverage of core-specific testing scenarios with practical, well-documented examples. The MockT usage examples and generic function testing guidance are particularly valuable.
303-348: Solid examples of testing the testing utilities.The custom assertion and benchmark utility examples properly demonstrate self-testing patterns whilst avoiding circular dependencies.
349-439: Clear dependency policy with well-explained exceptions.The zero dependencies requirement is clearly articulated with appropriate exceptions for self-testing scenarios. The examples effectively demonstrate the principles whilst avoiding circular logic.
440-554: Comprehensive coverage of testing best practices.The performance testing, documentation examples, and edge case handling demonstrate thorough consideration of testing requirements for a foundational library.
555-569: Effective summary of testing principles.The seven-point summary effectively captures the essential testing requirements for the core package and reinforces the document's key messages.
testing_test.go (8)
1-12: Proper test file structure with good practices.The compile-time verification of interface implementation is excellent practice, and the imports are appropriate for the testing functionality.
13-25: Well-organised test structure using subtests.The use of subtests to organise MockT functionality testing is excellent practice and ensures comprehensive coverage of all MockT features.
27-287: Comprehensive assertion testing with potential circular dependency concern.The tests provide excellent coverage of all assertion functions with both success and failure scenarios. However, some tests use assertion functions to test themselves (e.g., using
AssertTrueto test other assertions), which could create circular dependencies as discussed in the TESTING_core.md documentation.Consider using standard
testingmethods for the base assertion tests to avoid circular logic, particularly in functions likeTestAssertEqualwhereAssertTrueis used to verify the result ofAssertEqual.
347-369: Proper concurrent testing with atomic operations.The use of
atomic.AddInt64andatomic.LoadInt64ensures thread-safe counter operations, and the test correctly verifies both successful execution and error propagation in concurrent scenarios.
371-404: Effective demonstration of TestCase interface pattern.The mockTestCase implementation and RunTestCases test properly demonstrate the table-driven testing pattern with clear verification that all test cases execute.
406-425: Correct benchmark testing pattern.The test properly verifies the benchmark setup and execution phases, ensuring the setup runs once and the execution function runs exactly N times.
427-593: Comprehensive MockT functionality testing.The detailed MockT tests thoroughly cover all functionality including state management, thread safety, formatted logging, and reset operations. The test helper functions are well-structured and follow good testing practices.
594-633: Excellent concurrent safety testing for MockT.The concurrent test properly exercises MockT under concurrent load with well-calculated expected operation counts. This ensures MockT's thread safety for use in concurrent testing scenarios.
TESTING.md (6)
1-37: Well-structured introduction and clear mandatory requirements.The document effectively establishes testing guidelines with clear principles and mandatory compliance requirements that ensure consistency across all darvaza.org projects.
38-185: Comprehensive testing utilities documentation with excellent examples.The detailed explanation of testing utilities, assertion functions, and hierarchy guidelines provides clear guidance for consistent test implementation. The examples effectively demonstrate proper usage patterns.
186-287: Excellent test structure patterns with clear implementation steps.The step-by-step guide for implementing compliant test structures is comprehensive and practical. The emphasis on factory functions for decoupling parameter order from field alignment is a crucial design consideration.
288-722: Outstanding documentation of complexity management and factory patterns.The comprehensive coverage of anonymous function limits, helper method extraction, and various factory function patterns provides exceptional guidance. The critical explanation of parameter reordering for field alignment (lines 653-711) is particularly valuable for understanding why factory functions are mandatory.
723-949: Thorough coverage of testing patterns and best practices.The documentation effectively covers field alignment, concurrent testing, benchmarking, MockT usage, error testing patterns, and integration with CI/CD. The best practices section provides clear, actionable guidance.
950-1111: Excellent forbidden patterns documentation and compliance checklist.The clear examples of forbidden patterns paired with correct alternatives provide invaluable guidance. The compliance checklist (lines 1078-1093) offers a practical verification tool, and the summary effectively reinforces the mandatory nature of these guidelines.
slices_test.go (1)
1-63: Exemplary implementation of mandatory testing patterns.The file correctly implements all 6 mandatory TestCase compliance requirements: interface validations, factory functions, TestCase interface implementation, RunTestCases usage, and proper test structure.
generics_test.go (2)
1-190: Perfect compliance with testing guidelines for generic types.The implementation demonstrates excellent handling of generic test cases while maintaining full compliance with all mandatory testing requirements. The factory functions and interface implementations are particularly well done.
396-427: Good extraction of helper functions for test clarity.The helper functions
evaluateYesFunctionandevaluateNoFunctionare properly extracted to improve test readability and maintain focus on the test logic.panicerror_test.go (2)
1-93: Excellent decomposition of complex test logic.The test implementation demonstrates best practices by breaking down complex test logic into focused helper methods (lines 44-84). This approach maintains compliance with complexity limits while improving readability.
233-310: Well-structured panic testing with focused helper methods.The decomposition of panic validation logic into specific helper methods (validatePanicFunction, extractPanicError, validatePanicPayload) demonstrates excellent adherence to complexity management guidelines.
testing.go (4)
1-135: Excellent thread-safe MockT implementation.The MockT struct provides a robust mock implementation with proper thread safety using sync.RWMutex. The query methods (HasErrors, LastError, HasLogs, LastLog) and Reset functionality enable comprehensive testing of test utilities.
178-283: Well-designed assertion helpers following hierarchy principles.The assertion functions demonstrate proper base/derived relationships (e.g., AssertError delegates to AssertNotNil) and consistent implementation patterns. The use of generics provides type safety while maintaining flexibility.
345-363: Correct implementation of boolean assertions.The delegation to AssertEqual follows the documented base/derived function pattern. The revive:disable comments are appropriately used for the flag-parameter rule, which doesn't apply to assertion functions testing boolean values.
442-477: Solid concurrent testing and benchmarking utilities.The implementations follow Go best practices: RunConcurrentTest properly manages goroutines with WaitGroup and error collection via channels, while RunBenchmark correctly separates setup from timed execution.
panic_test.go (8)
9-20: Excellent use of compile-time interface verification.This ensures all test case types properly implement the TestCase interface, catching any interface compliance issues at compile time rather than runtime.
22-92: Well-structured refactoring of asRecoveredTestCase.The refactoring successfully:
- Implements the TestCase interface pattern
- Adds constructor for consistent instantiation
- Separates test logic into focused helper methods
- Improves handling of different recovered value types (pass-through, string-to-error conversion, etc.)
The code is more maintainable and follows the established testing patterns.
98-160: Consistent refactoring with proper use of assertion helpers.The catcherDoTestCase successfully adopts the TestCase interface pattern and properly uses:
AssertError/AssertNoErrorfor error checkingAssertTypeIsfor type assertionsAssertNotNilfor nil checksThis maintains consistency with the new testing infrastructure.
221-246: Good adoption of standardised assertion helpers.The test properly uses
AssertNil,AssertNotNil,AssertEqual, andAssertTypeIshelpers, improving consistency with the testing infrastructure.
248-285: Proper use of assertion helpers in concurrent test.The concurrent test correctly uses
AssertNotNil,AssertTrue, andAssertTypeIswhile maintaining the essential concurrent testing logic.
391-595: Excellent comprehensive test coverage for Must/Maybe utilities.The test implementation demonstrates:
- Thorough coverage of success and panic scenarios
- Generic test helpers reducing code duplication
- Proper verification of panic wrapping with stack traces
- Testing across multiple types (primitives, slices, pointers, structs)
- Awareness of struct field ordering for memory optimization
This provides robust validation of the new utility functions.
597-806: Comprehensive test coverage for MustOK/MaybeOK utilities.The tests mirror the Must/Maybe pattern effectively:
- Success scenarios when
ok=true- Panic scenarios when
ok=falsewith message verification- Consistent use of generic test helpers
- Coverage across multiple types
The implementation maintains consistency with the Must/Maybe tests while properly validating the boolean-based variants.
484-484: Consistent use of S() slice creation helper.The code properly uses the
S()helper function for slice creation, maintaining consistency with the testing infrastructure patterns.Also applies to: 689-689, 744-744
| AssertEqual(t, true, IsNil(vi), "typed nil") | ||
|
|
||
| // Test slice with nil elements | ||
| ptrSlice := []*int{nil, nil, nil} // array literal, not slice |
There was a problem hiding this comment.
Fix misleading comment about array vs slice.
The comment states "array literal, not slice" but the code []*int{nil, nil, nil} creates a slice, not an array. In Go, this syntax creates a slice literal. An array literal would be [3]*int{nil, nil, nil}.
Either update the comment to reflect that it's a slice, or change the code to use an actual array if that was the intent:
- ptrSlice := []*int{nil, nil, nil} // array literal, not slice
+ ptrSlice := []*int{nil, nil, nil} // slice literal with nil elementsOr if an array was intended:
- ptrSlice := []*int{nil, nil, nil} // array literal, not slice
+ ptrArray := [3]*int{nil, nil, nil} // array literal, not slice📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ptrSlice := []*int{nil, nil, nil} // array literal, not slice | |
| - ptrSlice := []*int{nil, nil, nil} // array literal, not slice | |
| + ptrSlice := []*int{nil, nil, nil} // slice literal with nil elements |
🤖 Prompt for AI Agents
In zero_test.go at line 685, the comment incorrectly states that the code
creates an array literal, but the syntax `[]*int{nil, nil, nil}` actually
creates a slice literal. To fix this, either update the comment to say "slice
literal, not array" to accurately describe the code, or if the intent was to
create an array, change the code to `[3]*int{nil, nil, nil}` to define an array
literal.
karasz
left a comment
karasz
left a comment
There was a problem hiding this comment.
LGTM - Excellent work.
I especially like the Must/Maybe thingies which are implemented very nicely and I think that the examples are enough to get anyone started.
Thank you for the high quality work as usual.
|
Released as v0.18.0: https://github.com/darvaza-proxy/core/releases/tag/v0.18.0 go get darvaza.org/core@v0.18.0 |
Transform testing infrastructure to public API, add Must/Maybe utilities
Summary
Major overhaul that transforms darvaza.org/core from an internal utility
library to a comprehensive testing ecosystem with public APIs, plus adds
Must/Maybe and MustOK/MaybeOK generic utilities for error and boolean handling.
Key Achievements:
Changes Overview
🧪 Testing Infrastructure Transformation
Public API Creation:
testutils_test.goto publictesting.go(537 lines)Tinterface for both*testing.TandMockTcompatibilitytesting_test.go(479 lines) for self-testing validationEnhanced Assertion Functions:
AssertEqual,AssertNotEqual,AssertError,AssertPanic,AssertTypeIs, etc.functions
Advanced Testing Utilities:
S[T]()for concise slice creation:S(1, 2, 3)instead of[]int{1, 2, 3}RunConcurrentTest()for goroutine-based testing with proper synchronisationRunBenchmark()with setup/execution phase separationMockTimplementation for testing assertion functions themselves🔧 Must/Maybe Generic Utilities
New Error Handling Functions:
Must[T](value T, err error) T- panics withPanicErrorif err != nil,returns value if err == nil
Maybe[T](value T, err error) T- always returns value, ignoring any errorNew Boolean-based Functions:
MustOK[T](value T, ok bool) T- panics withPanicErrorif ok == false,returns value if ok == true
MaybeOK[T](value T, ok bool) T- always returns value, ignoring ok statusUse Cases:
📚 Documentation & Guidelines
New Documentation Files:
TESTING.md(1104 lines) - Organisation-wide testing patterns and standardsTESTING_core.md(525 lines) - Core-specific testing patterns andself-testing approaches
AGENT.mdandREADME.mdwith new testing infrastructure guidanceTesting Standards:
t.Runlimited to ≤3 lines🔄 Comprehensive Test Refactoring
18 test files transformed:
Assert*functionstest()methodsExamples of improvements:
⚙️ Configuration & Build
VS Code Integration:
internal/build/cspell.jsonUpdated Dependencies:
Test Results
Coverage Improvement:
All builds pass:
make all coverage)Files Changed
Statistics:
Key file changes:
testing.go- NEW: 537 lines of public testing utilitiestesting_test.go- NEW: 479 lines of self-testing validationTESTING.md- NEW: 1104 lines of testing guidelinesTESTING_core.md- NEW: 525 lines of core-specific patternspanic.go- ADDED: 75 lines for Must/Maybe and MustOK/MaybeOK utilitiestestutils_test.go- REMOVED: 285 lines (moved to public API)Benefits
For darvaza.org Ecosystem
For External Users
For Development
Remaining Considerations
Complexity Issues:
test coverage
Future Improvements:
Commits
refactor: clean up spelling dictionary and standardise camelCase namingfeat(testing): transform testing infrastructure to public API with comprehensive utilitiesdocs(testing): add comprehensive testing guidelines and patternsfeat(testing): add AssertNotEqual function for inequality assertionsrefactor(tests): implement TestCase interface across all test filesfeat: add Must/Maybe generic utilities for error handlingfeat: add MustOK/MaybeOK generic utilities for bool-based operationsThis PR represents a significant milestone in the evolution of
darvaza.org/core from a simple utility library to a comprehensive foundation
for the entire ecosystem, with particular emphasis on testing excellence and
error handling convenience.
PR Type
Enhancement, Tests, Documentation
Description
• Transform testing infrastructure to public API: Move testing utilities
from private
testutils_test.goto publictesting.gowith 15+ assertionfunctions (
AssertEqual,AssertNotEqual,AssertError,AssertPanic,etc.) and comprehensive testing utilities
• Add Must/Maybe and MustOK/MaybeOK generic utilities: Implement
Must[T]()andMustOK[T]()for panic-on-error/false patterns, andMaybe[T]()andMaybeOK[T]()for error/boolean-ignoring operations• Comprehensive test refactoring: Update 18 test files to use
standardised assertion functions, extract helper methods to reduce
complexity, and implement consistent testing patterns
• Create extensive documentation: Add
TESTING.md(1104 lines) fororganisation-wide testing standards and
TESTING_core.md(525 lines) forcore-specific patterns
• Self-testing capabilities: Implement
MockTfor testing assertionfunctions themselves with 480 lines of validation tests
• Configuration improvements: Centralize spell check configuration via
symlinks and update dictionaries for new utilities
• Enhanced test coverage: Achieve +0.4% improvement (96.5% → 96.9%)
with better assertion patterns and comprehensive edge case testing
Diagram Walkthrough
flowchart LR A["testutils_test.go (private)"] -- "transform" --> B["testing.go (public API)"] B --> C["15+ Assertion Functions"] B --> D["MockT Implementation"] E["panic.go"] -- "add" --> F["Must[T] utility"] E --> G["Maybe[T] utility"] H["18 Test Files"] -- "refactor" --> I["Standardized Assertions"] J["Documentation"] -- "create" --> K["TESTING.md"] J --> L["TESTING_core.md"] M["testing_test.go"] -- "validate" --> BFile Walkthrough
15 files
zero_test.go
Comprehensive refactoring of zero value testing with genericszero_test.go
• Refactored test structure from function-based to type-based test
cases with generic support
• Added comprehensive test coverage for
both nil and non-nil pointer scenarios across all types
• Replaced
manual assertions with standardized
AssertEqual,AssertNil, andAssertTruefunctions• Expanded
IsZerotests with additional numerictypes and edge cases including reflect.Value handling
maps_test.go
Standardized map testing with assertion functionsmaps_test.go
• Replaced manual error reporting with standardized assertion
functions (
AssertEqual,AssertTrue,AssertFalse)• Simplified test
logic by using
SliceContainshelper for key verification• Updated
assertion messages to be more concise and consistent
• Removed
cognitive complexity directive and improved code readability
testing_test.go
Complete test suite for new public testing infrastructuretesting_test.go
• Added comprehensive test suite for new public testing API with 480
lines of test code
• Tests cover
MockTimplementation, assertionfunctions, and concurrent testing utilities
• Validates all 14+
assertion functions including
AssertEqual,AssertPanic,AssertTypeIs•
Includes tests for
Shelper function,RunConcurrentTest, andRunBenchmarkutilitiesstack_test.go
Improved assertion messages in stack testsstack_test.go
• Updated assertion messages to be more concise and descriptive
•
Replaced verbose assertion messages with shorter, clearer descriptions
• Maintained all existing test functionality while improving
readability
• Applied consistent message formatting across
stack-related tests
panic_test.go
Add Must/Maybe tests and refactor panic handling testspanic_test.go
• Refactored test methods to extract helper functions and reduce
cognitive complexity
• Added comprehensive tests for new Must/Maybe
utility functions with success and panic scenarios
• Replaced manual
assertions with standardized AssertEqual/AssertError functions
•
Improved test structure with proper field alignment and type-safe
testing patterns
errgroup_test.go
Refactor ErrGroup tests with helper methods and assertionserrgroup_test.go
• Extracted complex test logic into smaller helper methods to meet
complexity requirements
• Replaced manual error checking with
standardized AssertError/AssertNoError functions
• Improved test
readability by separating concerns into focused helper functions
•
Enhanced error message consistency across test cases
lists_test.go
Improve list test assertions and message formattinglists_test.go
• Replaced AssertBool calls with more specific
AssertTrue/AssertFalse/AssertEqual functions
• Improved assertion
message formatting with better context and indexing
• Enhanced test
readability with more descriptive assertion prefixes
• Standardized
error message patterns across list operation tests
slices_test.go
Enhance slice test assertions and formattingslices_test.go
• Updated assertion calls to use more specific functions (AssertEqual
vs AssertBool)
• Improved test message formatting with better context
and parameter information
• Enhanced readability of slice operation
test assertions
• Standardized assertion patterns across slice utility
tests
errors_test.go
Standardize error test assertions and messagingerrors_test.go
• Replaced AssertBool with AssertEqual for better type safety and
readability
• Improved assertion message consistency and clarity
across error handling tests
• Enhanced test structure with more
descriptive assertion prefixes
• Standardized error testing patterns
for temporary and timeout error checks
panicerror_test.go
Refactor panic error tests with helper methodspanicerror_test.go
• Refactored complex test methods into smaller helper functions to
reduce cognitive complexity
• Replaced manual error checking with
standardized assertion functions
• Added proper test structure with
extracted validation methods
• Improved test readability and
maintainability through method extraction
waitgroup_test.go
Refactor WaitGroup tests with helper methods and assertionswaitgroup_test.go
• Extracted test logic into helper methods to reduce complexity and
improve readability
• Replaced manual error checking with
AssertError/AssertNoError functions
• Improved test structure by
separating async error handling from result validation
• Enhanced
consistency in error message validation patterns
context_test.go
Standardize context tests with assertion functionscontext_test.go
• Replaced manual if-checks with standardized assertion functions
•
Improved test readability with AssertEqual, AssertTrue, AssertFalse
calls
• Enhanced assertion message consistency across context key and
timeout tests
• Simplified test logic by using core testing utilities
as_test.go
Refactor type conversion tests with helper methodsas_test.go
• Refactored complex test method into smaller helper functions for
different conversion types
• Added constant for repeated test string
value to improve maintainability
• Extracted type-specific test logic
into focused helper methods
• Improved test structure and reduced
cognitive complexity
spinlock_test.go
Standardize SpinLock test assertions and messagingspinlock_test.go
• Updated assertion calls to use standardized AssertEqual and
AssertNoError functions
• Improved assertion message formatting and
consistency
• Enhanced test readability with more descriptive
assertion prefixes
• Standardized error handling patterns in
concurrent testing scenarios
addrs_test.go
Extract address test helper function for better organizationaddrs_test.go
• Extracted complex test function into separate helper function for
better organization
• Improved test structure by separating interface
testing logic
• Enhanced code readability through function extraction
• Maintained test functionality while improving maintainability
2 files
testing.go
New public testing API with assertion functions and utilitiestesting.go
• Created comprehensive public testing API with 537 lines including
Tinterface and
MockTimplementation• Added 15+ assertion functions
with generic support and consistent error/success logging
•
Implemented testing utilities like
Shelper,RunConcurrentTest, andRunBenchmark• Provides standardized testing patterns for the entire
darvaza.org ecosystem
panic.go
Add Must/Maybe generic error handling utilitiespanic.go
• Added Must[T] and MustOK[T] functions that panic with PanicError if error/ok condition fails
• Added Maybe[T] and MaybeOK[T] functions that always
return value, ignoring error/ok status
• Implemented common Go error
handling and boolean operation patterns for test setup and optional operations
• Enhanced
panic handling utilities with generic type safety and proper stack
traces
3 files
cspell.json
Updated spell check dictionary for new utilitiesinternal/build/cspell.json
• Added technical terms for new testing utilities:
Logf,mykey,strconv,Atoi,conn• Removed obsolete terms from spell check
dictionary
• Updated dictionary to support new Must/Maybe utility
functions and testing infrastructure
cspell.json
Centralized spell check configuration via symlink.vscode/cspell.json
• Replaced inline spell check configuration with symlink to
centralized
internal/build/cspell.json• Ensures consistent spell
checking between IDE and build system
• Eliminates duplication of
spell check word lists
settings.json
Simplify VS Code settings configuration.vscode/settings.json
• Replaced inline cSpell.words configuration with empty object
•
Simplified VS Code settings by removing custom spell check words
•
Likely indicates migration to centralized spell checking configuration
4 files
TESTING.md
Add comprehensive testing guidelines documentationTESTING.md
• Created comprehensive testing guidelines document for all
darvaza.org projects
• Documented testing utilities, assertion
functions, and best practices
• Established patterns for test
structure, complexity management, and field alignment
• Provided
examples and forbidden patterns to ensure consistency across projects
TESTING_core.md
Add core-specific testing patterns documentationTESTING_core.md
• Created core-specific testing documentation for self-testing
patterns
• Documented MockT usage for testing assertion functions
themselves
• Provided guidelines for testing generic functions and
zero-dependency requirements
• Established patterns for performance
testing and edge case handling
README.md
Update README with Must/Maybe utilities and testing documentationREADME.md
• Added documentation for new Must/Maybe utility functions with usage
examples
• Enhanced testing utilities section with comprehensive
feature overview
• Added references to new testing documentation files
• Improved formatting and organization of existing content sections
AGENT.md
Update agent documentation for new testing infrastructureAGENT.md
• Added references to new testing documentation files (TESTING.md and
TESTING_core.md)
• Replaced detailed test helper function
documentation with references to external testing guides
• Simplified
testing patterns section to focus on public API usage
• Updated
development guidelines to point to comprehensive testing documentation
1 files
testutils_test.go
Remove private testing utilities (moved to public API)testutils_test.go
• Deleted private testing utilities file (285 lines removed)
•
Testing utilities moved to public API in testing.go
• Enables
external packages to use testing utilities
• Part of transformation
from internal to public testing infrastructure
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Must,Maybe,MustOK,MaybeOK).Documentation
Bug Fixes
Refactor
Chores
Revert