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