golang-stretchr-testifylisted

# Testify in Go tests Keep Go's `testing` package as the test runner and match the repository's existing assertion style. Use Testify where its diagnostics, suites, or mocks improve the test; a direct `if` remains appropriate when clearer. ## Inspect before editing Check `go.mod`, package-level assertion conventions, helper functions, mock-generation or hand-written mock patterns, suite usage, parallel tests, and linters such as `testifylint`. Verify APIs against the selected version before adopting newer assertions or mock helpers. ## Assertions and requirements - Use `require` for a failed precondition after which continuing would panic or make later results meaningless. - Use `assert` when independent checks can still provide useful diagnostics after one fails. - Keep expected and actual argument order correct for assertions that distinguish them. - Use `ErrorIs`/`ErrorAs` for wrapped errors when identity or type matters; compare text only when text is the contract. - Testify equality assertions perform value-oriented comparison for supported values, including pointed-to data. Use identity-specific assertions when pointer identity itself is the behavior. `require` ultimately calls `FailNow`, so call it from the goroutine running the test rather than an asynchronous worker. Communicate worker failures back to that goroutine. Make callbacks used by eventual assertions concurrency-safe and give them meaningful time bounds. For concrete assertion selection, eventual che