-
Notifications
You must be signed in to change notification settings - Fork 130
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
DEVPROD-7742 Fix current testifylint lint issues (manual) #8604
DEVPROD-7742 Fix current testifylint lint issues (manual) #8604
Conversation
@@ -425,6 +425,7 @@ func TestGetResolvedPlannerSettings(t *testing.T) { | |||
// Fallback to the SchedulerConfig.ExpectedRuntimeFactor as PlannerSettings.ExpectedRunTimeFactor is equal to 0. | |||
assert.EqualValues(t, 7, resolved0.ExpectedRuntimeFactor) | |||
assert.EqualValues(t, 20, resolved0.GenerateTaskFactor) | |||
//nolint:testifylint // We expect it to be exactly 10. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, what does testifylint not like about this + the others? It seems like checking that some output value exactly matches an expected hard-coded value would be a normal thing to do in a test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These ones are checking float. Testifylint suggests we use a (I didn't know it existed) InEpsilon
assertion/require for floats to account for floating point number errors. I figured since our tests are passing, no reason to modify the behavior to check for a range.
DEVPROD-7742
Description
Before merging in the fix for our linter and adding stricter rules, I'm doing smaller PRs to fix the current mistakes that our linter should be catching.
This PR fixes the testifylint lint issues with manual changes. There weren't that many that autofix didn't fix, but these were the most valuable as it caught some bugs (e.g. we were panicing in some goroutines by using
require
in them, we also had an accidentalassert.Zero(t, 0, <actual_variable>....
so it always passed since it was asserting on the constant0
).This PR does not add the testifylint to our linters yet, this is blocked on upgrading our go version. The corresponding ticket is DEVPROD-13938.
Testing
Running golangci-lint run in my terminal results in no more lint errors. This pulls from the .golangci.yml file's configuration (which our linter task should be doing.