v0.18.1

Bug Fix

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

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

• 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

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.

v0.16.1

What's Changed

• feat: add a constructor with configuration structure by @ldez in #143

Full Changelog: v0.16.0...v0.16.1

v0.16.0

What's Changed

New Rules

Optional Rule: Force Expect with To [STYLE]

Trigger warning when using Expect with Should or ShouldNot`; e.g.

Expect(err).ShouldNot(HaveOccurred())

Should be

Expect(err).ToNot(HaveOccurred())

This rule is optional. Add the --force-expect-to=true to enable this rule.

Rule: cap assertion [STYLE]

Very similar to the len rule. The linter triggers a warning when using

Expect(cap(slice)).To(Equal(3))

Instead, the linter suggests

Expect(slice).To(HaveCap(3))

This rule is now part of the len rule. It uses the same configurations:

• enabled by default
• To suppress this warning, use the --suppress-len-assertion=true flag.
• To suppress this warning for a file, add a comment in the top of the file:

  // ginkgo-linter:ignore-len-assert-warning

• To suppress this warning for a specific expression, add the comment above the expression:

  // ginkgo-linter:ignore-len-assert-warning
  Expect(cap(slice)).To(Equal(3))

Optional Rule: validate async intervals [BUG and STYLE]

Note: This rule works as best-effort. It can't catch all cases.

This rule is disable by default. Use the --validate-async-intervals=true flag to enable it. Also, the --suppress-async-assertion flag must not be set to true. In this case, this rule is disabled.

This rule is actually three sub-rules

Timeout Must be Longer than Polling [BUG]

In async assertions (Eventually or Consistently), the linter checks that the timeout is not shorter than the polling interval.

For example:

Eventually(..., time.Millisecond * 500 /*timeout*/, 10 * time.Second /*polling*/)
// or:
Eventually(...).WithTimeout(time.Millisecond * 500).WithPolling(10 * time.Second)
// or any combination of the above

Avoid using non time.Duration for Timeout and Polling [STYLE]

ginkgo async functions support many forms for duration, when passing timeout and polling arguments. However, this is an old API, that is mostly there for backward compatible.

The linter now trigger a warning if the time interval are not of type time.Duration.

For example:

Eventually(..., 20 /*timeout of 20 seconds*/, "2s" /*polling of two seconds*/)

This rule support a very limited auto-fix option, when the value is an integer, or an integer const.

Avoid redefinition of timeout or polling [STYLE]

The linter only allow up to one polling and up to one timeout; e.g.

Eventually(..., time.Millisecond * 500 /*timeout*/, 10 * time.Second /*polling*/).WithTimeout(time.Millisecond * 500).WithPolling(10 * time.Second)
// or any combination of the above

Optional Rule: Avoid spec Pollution [BUG/STYLE]

To avoid test spec pollution, avoid assigning to variable within container nodes; see more info in ginkgo documentation.

The linter now enforce this rule; e.g.

var _ = Describe("spec pollution in Describe", func(){
    x := "spec pollution"
    ...
    Context("spec pollution in Context", func() {
        y := "another spec pollution"
        ...
    })
})

It should be done more like this:

var _ = Describe("spec pollution in Describe", func(){
    var x string
    BeforeEach(func(){
        x = "now no spec pollution"
    })
    ...
    Context("spec pollution in Context", func() {
        var y string
        ...
        BeforeEach(func(){
            y = "now no spec pollution"
        })
        ...
    })
})

This rule is disable by default. use the --forbid-spec-pollution=true flag to enable it.

Full Changelog: v0.15.2...v0.16.0

v0.15.2

What's Changed

• Fix issue: panic when using custom matchers by @nunnatsa in #126

Full Changelog: v0.15.1...v0.15.2

v0.15.1

Downgrade to golang v1.20, because golangci-lint needs to be built with go1.20, as go1.20 and go1.21 are the current versions of Go supported by the Go team. So, for now, golangci-lint should not depend on go1.21.

v0.15.0

What's Changed

New rule(s): Wrong Usage of the MatchError gomega Matcher

The MatchError gomega matcher asserts an error value (and if it's not nil).

There are four valid formats for using this Matcher:

• error value; e.g. Expect(err).To(MatchError(anotherErr))
• string, to be equal to the output of the Error() method; e.g. Expect(err).To(MatchError("Not Found"))
• A gomega matcher that asserts strings; e.g. Expect(err).To(MatchError(ContainSubstring("Found")))
• [from v0.29.0] a function that receive a single error parameter and returns a single boolean value. In this format, an additional single string parameter, with the function description, is also required; e.g. Expect(err).To(MatchError(isNotFound, "is the error is a not found error"))

These four format are checked on runtime, but sometimes it's too late. ginkgolinter performs a static analysis and so it will find these issues on build time.

ginkgolinter checks the following:

• Is the first parameter is one of the four options above.
• That there are no additional parameters passed to the matcher; e.g. MatchError(isNotFoundFunc, "a valid description" , "not used string"). In this case, the matcher won't fail on run time, but the additional parameters are not in use and ignored.
• If the first parameter is a function with the format of func(error)bool, ginkgolinter makes sure that the second parameter exists and its type is string.

Full Changelog: v0.14.1...v0.15.0

v0.14.1

Bug fixes

Type checker gives false positive for WithTransform + ContainElement (#115 )

ginkgolinter now only trigger warning for WithTransform with Equal or BeIdentical matchers.

Full Changelog: v0.14.0...v0.14.1