Skip to content

[BUG] False Positive for the MatchError matcher used to assert a non error type in Eventually cases #174

@maboehm

Description

@maboehm

Describe the bug
Using a function inside of Eventually() is not correctly handled by the linter.

This is accepted:

Eventually(func() error {
	return fmt.Errorf("an error")
}).Should(MatchError(ContainSubstring("error")))

But replacing the function declaration with a function that returns the function returns an error (see below), but is one way described even in the docs: https://onsi.github.io/gomega/#category-2-making-codeeventuallycode-assertions-on-functions and is equivalent to the in-line example

To Reproduce

package main_test

import (
	"fmt"
	"math/rand"
	"testing"

	. "github.com/onsi/ginkgo/v2"
	. "github.com/onsi/gomega"
)

func TestE2E(t *testing.T) {
	RegisterFailHandler(Fail)
	RunSpecs(t, "demo")
}


func bar() func() error {
	return func() error {
		return fmt.Errorf("an error")
	}
}

var _ = Describe("the MatchError matcher used to assert a non error type", func() {
	It("should work", func() {
		Eventually(bar()).Should(MatchError(ContainSubstring("error")))
	})
})

Results in

main_test.go:28:3: ginkgo-linter: the MatchError matcher used to assert a non error type (bar())

Expected behavior
No linting error

**E
Environment:

  • OS: macos
  • Version latest (0.18.1)
  • go: 1.22.9

Additional context
We first observed this when bumping golangci-lint, which bumped this linter from 0.16.0 to 0.18.0

Might be related to #173 since we started seeing it at the same time and both have to do with error checking.

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions