-
-
Notifications
You must be signed in to change notification settings - Fork 374
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
simple: simplify t.Errorf
patterns where applicable
#1561
Labels
Comments
Hi I'm a random gopher and I like your suggestion. One remark, what you are asking is more a checker about the presence of FailNow + preceded by Errorf, Error, Log, or Logf than a checker about the Errorf usage. |
dominikh
added
new-check
and removed
needs-triage
Newly filed issue that needs triage
labels
Jun 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've noticed a few t.Errorf patterns during code review that work but could be simplified. They're not significant enough to manually flag in review, but I'd enforce it via a linter if
simple
supported them. All of my examples will use t.Errorf, but the same argument could be made for t.Error (or theirB
,F
, orTB
equivalents).Is a rule like this something that could be a good fit for
simple
?Unnecessary t.Fail()
Example from one of my repos, where the
t.Fail()
call can be removed:should be
t.Fatalf could be used instead
Always equivalent
t.Errorf
followed byt.FailNow
can be replaced byt.Fatalf
Example occurrence from kubernetes/kubernetes
should be
Sometimes equivalent
t.Errorf
followed byreturn
can sometimes be replaced byt.Fatalf
. Google's style guide documents one case where this isn't true. To avoid issues of knowing when we're in a goroutine, the suggestion could only apply to occurrences directly in a top level test (TestFoo (t *testing.T)
) or directly in at.Run
.example
should be
not equivalent example
Example not to flag:
The text was updated successfully, but these errors were encountered: