What's Changed

Added new linter rule.

New Linter Rule

Force assertion descriptions [STYLE] (#200)

Note: This rule does not support auto-fix.

Correct Usage of the Succeed() and the HaveOccurred() matchers [STYLE]

This rule enforces that all assertions include an optional description message to improve test readability and debugging.

It("should test something", func() {
    Expect("hello").To(Equal("hello")) // This will trigger a warning
    Eventually(func() bool { return true }).Should(BeTrue()) // This will trigger a warning
})

Should be:

It("should test something", func() {
    Expect("hello").To(Equal("hello"), "greeting should match")
    Eventually(func() bool { return true }).Should(BeTrue(), "condition should eventually be true")
})

This rule is disabled by default. Use the --force-assertion-description command line flag to enable it.

Note: This rule does not support auto-fix.

CLI Changes

Added the new --force-assertion-description=true command line parameter, to enable the "Force assertion descriptions" rule.

New Contributors

• @bootuz made their first contribution in #200

Full Changelog: v0.19.1...v0.20.0

What's Changed

• Improve IsGomegaVar() and IsGomegaType() by @nunnatsa in #189
• fix: type aliases by @ldez in #187
• Fix issue: failed to recognize ginkgo.SpecContext in Eventually by @nunnatsa in #191

Full Changelog: v0.19.0...v0.19.1

Bump golang to 1.23

Fix issue with golang 1.23 - fail to identify the Gomega variable

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

What's Changed

• fix: downgrade min Go by @ldez in #176

Full Changelog: v0.18.2...v0.18.3

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())

Bug Fix

Fix #171: A function variable with nil value cannot be asserted with BeNil()

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

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"))

• Bug fix: handle Equal(true/false) in Expect(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 with To rule now also checks ExpectWithOffset(); 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

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.