@@ -136,7 +136,6 @@ Describe a new checker in [checkers section](./README.md#checkers).
136
136
- [ float-compare] ( #float-compare )
137
137
- [ http-const] ( #http-const )
138
138
- [ http-sugar] ( #http-sugar )
139
- - [ no-fmt-mess] ( #no-fmt-mess )
140
139
- [ require-len] ( #require-len )
141
140
- [ suite-run] ( #suite-run )
142
141
- [ suite-test-name] ( #suite-test-name )
@@ -305,44 +304,6 @@ And similar idea for `assert.InEpsilonSlice` / `assert.InDeltaSlice`.
305
304
306
305
---
307
306
308
- ### no-fmt-mess
309
-
310
- ** Autofix** : true. <br >
311
- ** Enabled by default** : maybe? <br >
312
- ** Related issues** : [ #33 ] ( https://github.com/Antonboom/testifylint/issues/33 )
313
-
314
- Those who are new to ` testify ` may be discouraged by the duplicative API:
315
-
316
- ``` go
317
- func Equal (t TestingT , expected , actual interface {}, msgAndArgs ...interface {}) bool
318
- func Equalf(t TestingT, expected interface{}, actual interface {}, msg string , args ...interface {}) bool
319
- ```
320
-
321
- The f-functions [ were added a long time ago] ( https://github.com/stretchr/testify/pull/356 ) to eliminate
322
- ` govet ` [ complain] ( https://go.googlesource.com/tools/+/refs/heads/release-branch.go1.12/go/analysis/passes/printf/printf.go?pli=1#506 ) .
323
-
324
- This introduces some inconsistency into the test code, and the next strategies are seen for the checker:
325
-
326
- 1 ) Forbid f-functions at all (also could be done through the [ forbidigo] ( https://golangci-lint.run/usage/linters/#forbidigo ) linter).
327
-
328
- This will make it easier to migrate to [ v2] ( https://github.com/stretchr/testify/issues/1089 ) , because
329
-
330
- > Format functions should not be accepted as they are equivalent to their "non-f" counterparts.
331
-
332
- But it doesn't look like a "go way" and the ` govet ` won't be happy.
333
-
334
- 2 ) IMHO, a more appropriate option is to disallow the use of ` msgAndArgs ` in non-f assertions. Look at
335
- [ the comment] ( https://github.com/stretchr/testify/issues/1089#issuecomment-1695059265 ) .
336
-
337
- But there will be no non-stylistic benefits from the checker in this case (depends on the view of API in ` v2 ` ).
338
-
339
- Also, in the first iteration ` no-fmt-mess ` checker could help to avoid code like this:
340
- ``` go
341
- assert.Error (t, err, fmt.Sprintf (" Profile %s should not be valid" , test.profile ))
342
- ```
343
-
344
- ---
345
-
346
307
### require-len
347
308
348
309
The main idea: if code contains array/slice indexing,
0 commit comments