Skip to content

chore: replace t.Errorf/t.Fatalf with assert/require in go/vt/servenv#19518

Open
ManthanNimodiya wants to merge 1 commit intovitessio:mainfrom
ManthanNimodiya:chore/replace-t-errorf-fatalf-servenv
Open

chore: replace t.Errorf/t.Fatalf with assert/require in go/vt/servenv#19518
ManthanNimodiya wants to merge 1 commit intovitessio:mainfrom
ManthanNimodiya:chore/replace-t-errorf-fatalf-servenv

Conversation

@ManthanNimodiya
Copy link

Description

Replace t.Errorf and t.Fatalf calls with testify assert and require equivalents
in the go/vt/servenv package, as part of the test suite modernization tracked in #15182.

  • t.Fatalf(...)require.NoError(t, err) for fatal error checks in normal test flow
  • t.Errorf(...)assert.NoError(t, err) for non-fatal checks (including inside goroutines
    where require cannot be used safely)
  • Range checks converted to assert.True(t, condition, msg) with equivalent semantics

Related Issue(s)

Fixes part of #15182

Checklist

  • "Backport to:" labels have been added if this change should be back-ported to release branches
  • If this change is to be back-ported to previous releases, a justification is included in the PR description
  • Tests were added or are not required
  • Did the new or modified tests pass consistently locally and on CI?
  • Documentation was added or is not required

Deployment Notes

No deployment impact — test-only changes.

AI Disclosure

This PR was written with assistance from AI

Part of vitessio#15182. Modernizes test assertions in the servenv package:
- t.Fatalf → require.NoError for fatal checks in normal test flow
- t.Errorf → assert.NoError inside goroutines (require unsafe in goroutines)
- Range checks converted to assert.True with equivalent semantics
@github-actions github-actions bot added this to the v24.0.0 milestone Feb 27, 2026
@vitess-bot vitess-bot bot added NeedsWebsiteDocsUpdate What it says NeedsDescriptionUpdate The description is not clear or comprehensive enough, and needs work NeedsIssue A linked issue is missing for this Pull Request NeedsBackportReason If backport labels have been applied to a PR, a justification is required labels Feb 27, 2026
@vitess-bot
Copy link
Contributor

vitess-bot bot commented Feb 27, 2026

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

  • Ensure that the Pull Request has a descriptive title.
  • Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

  • Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

  • Apply the release notes (needs details) label if users need to know about this change.
  • New features should be documented.
  • There should be some code comments as to why things are implemented the way they are.
  • There should be a comment at the top of each new or modified test to explain what the test does.

New flags

  • Is this flag really necessary?
  • Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

  • Each item in Jobs should be named in order to mark it as required.
  • If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

  • Protobuf changes should be wire-compatible.
  • Changes to _vt tables and RPCs need to be backward compatible.
  • RPC changes should be compatible with vitess-operator
  • If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
  • vtctl command output order should be stable and awk-able.

@mattlord
Copy link
Member

mattlord commented Feb 27, 2026

I don't personally want to review a hundred of these kinds of PRs. I think that we should do it all in one PR, so that one PR resolves the issue. This is the kind of thing that OpenCode/Claude/Codex/Cursor etc could do very quickly and easily now — across all of the tests.

@ManthanNimodiya
Copy link
Author

Thanks for the feedback, @mattlord!
Totally understand

Just to confirm: you'd prefer one PR that replaces all t.Errorf/t.Fatalf occurrences across the entire codebase at once?
I'll close this one and open a consolidated PR once the full replacement is ready.

@mattlord
Copy link
Member

Thanks for the feedback, @mattlord! Totally understand

Just to confirm: you'd prefer one PR that replaces all t.Errorf/t.Fatalf occurrences across the entire codebase at once? I'll close this one and open a consolidated PR once the full replacement is ready.

I would personally, yes. It should be something that e.g. Claude could kick out in literally a minute or so. Then we have one PR to review, one set of CI runs, etc. We can also ask AI to review it as well. :-D

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

Modernizes go/vt/servenv tests by replacing t.Errorf/t.Fatalf usages with testify/assert and testify/require, aligning with the broader test-suite modernization effort in #15182.

Changes:

  • Convert fatal error checks to require.NoError in liveness_test.go and exporter_test.go.
  • Convert non-fatal validations to assert.NoError / assert.True in metrics_test.go.
  • Update imports accordingly to include testify helpers.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
go/vt/servenv/metrics_test.go Replaces manual error/range checks with assert-based validations for CPU/memory metric helpers.
go/vt/servenv/liveness_test.go Replaces t.Fatalf error handling with require.NoError for HTTP request/response reads.
go/vt/servenv/exporter_test.go Replaces listener setup fatal check with require.NoError and uses assert.NoError for the HTTP server goroutine.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines 45 to 48
go func() {
err := HTTPServe(listener)
if err != nil {
t.Errorf("HTTPServe returned: %v", err)
}
assert.NoError(t, err)
}()
Copy link

Copilot AI Feb 27, 2026

Choose a reason for hiding this comment

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

assert.NoError(t, err) is being called from a goroutine. Using *testing.T (and testify assertions that wrap it) from a goroutine without synchronization can race with the test finishing and can trigger "testing: ... after Test... has completed" panics/flakes. Consider sending the HTTPServe result on a channel and asserting in the main test goroutine (or wait for the goroutine to exit before TestHandleFunc returns).

Copilot uses AI. Check for mistakes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

NeedsBackportReason If backport labels have been applied to a PR, a justification is required NeedsDescriptionUpdate The description is not clear or comprehensive enough, and needs work NeedsIssue A linked issue is missing for this Pull Request NeedsWebsiteDocsUpdate What it says

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants