Releases: nunnatsa/ginkgolinter
v0.19.1
v0.19.0
v0.18.4
What's Changed
Bug Fixes
Fix false positive when asserting an error pointer #183
CLI improvements
no need to implicitly specify =true
for command line flags
New Contributors
- @alexandear made their first contribution in #179
Full Changelog: v0.18.3...v0.18.4
v0.18.3
v0.18.2
What's Changed
Bug fix: false positive for func returns error func #174
The linter triggers a warning for this case:
func errFunc() func() error {
return func() error {
return errors.New("error")
}
}
var _ = Describe("test if issue 174 was solved", func() {
It("should not trigger", func() {
Eventually(errFunc()).Should(MatchError(ContainSubstring("error")))
})
})
The linter fails to identify the actual value as error value.
Bug Fix: ginkgolinter ignores the Error() method #173
as in:
Expect(func() (int, error) {return 42, nil}()).Error().ToNot(HaveOccurred())
v0.18.1
v1.18.0
What's Changed
Added two new rules, to validate the Success
and HaveOccurred
matchers
New Linter Rules
Prevent Wrong Actual Values with the Succeed()
matcher [Bug]
The Succeed()
matcher only accepts a single error value. this rule validates that.
For example:
Expect(42).To(Succeed())
But mostly, we want to avoid using this matcher with functions that return multiple values, even if their last returned value is an error, because this is not supported:
Expect(os.Open("myFile.txt")).To(Succeed())
In async assertions (like Eventually()
), the Succeed()
matcher may also been used with functions that accept a Gomega
object as their first parameter, and returns nothing, e.g. this is a valid usage of Eventually
Eventually(func(g Gomega){
g.Expect(true).To(BeTrue())
}).WithTimeout(10 * time.Millisecond).WithPolling(time.Millisecond).Should(Succeed())
Note: This rule does not support auto-fix.
Correct Usage of the Succeed() and the HaveOccurred()
matchers [STYLE]
This rule enforces using the Success()
matcher only for functions, and the HaveOccurred()
matcher only for error values.
For example:
Expect(err).To(Succeed())
will trigger a warning with a suggestion to replace the mather to
Expect(err).ToNot(HaveOccurred())
and vice versa:
Expect(myErrorFunc()).ToNot(HaveOccurred())
will trigger a warning with a suggestion to replace the mather to
Expect(myErrorFunc()).To(Succeed())
This rule is disabled by default. Use the --force-succeed=true
command line flag to enable it.
Note: This rule does support auto-fix, when the --fix
command line parameter is used.
CLI Changes
Added the new --force-succeed=true
command line parameter, to enable the "Correct Usage of the Succeed() and the HaveOccurred() matchers" rule.
Full Changelog: v0.17.0...v0.18.0
v0.17.0
What's Changed
-
Bug fix: missing async validations
- the linter now checks error with nil assertion also in async assertions as well, such as:
Eventually(func() err {return nil}).Should(BeNil())
- the linter now checks for
MatchError
issues in async assertions as well, e.g.Eventually(func() string {return "hello"}).Should(MatchError("hello"))
- the linter now checks error with nil assertion also in async assertions as well, such as:
-
Bug fix: handle
Equal(true/false)
inExpect(p == nil).To(Equal(true/false))
even when nil assertion is suppressed; e.g.Expect(p == nil).To(Equal(true)) // will be changed to: Expect(p == nil).To(BeTrue())
-
Bug fix: force
Expect
withTo
rule now also checksExpectWithOffset()
; e.g.ExpectWithOffset(err).ShouldNot(HaveOccurred()) // will be changed to: ExpectWithOffset(err).ToNot(HaveOccurred())
-
Bump go to v1.22
-
[internal] Huge Refactoring
- separate parsing and processing from validation
- introduce gomega expression Rules
Full Changelog: v0.16.2...v0.17.0
v0.16.2
Bug Fix: false positive for in avoid spec pollution rule
In case of assignment to undescore (_
), the linter triggered a warning. But in this case there is no spec pollution, because there is no variable to be changed during the test.
This fix changes the linter to ignore assignments to underscores.