Skip to content

Conversation

@pohly
Copy link
Contributor

@pohly pohly commented Dec 17, 2025

Description

In Kubernetes' ktesting package the following assertion is valid:

    tCtx.Eventually(func(tCtx TContext) {}).Should(Succeed())

That works because tCtx.Eventually wraps the function such that failures reported via tCtx.Error/Errorf/Fatal/Fatalf are visible to the matcher.

Without this change, the "Success matcher only support a single error value, or function with Gomega as its first parameter" warning is triggered.

Instead of building in specific support for ktesting, the approach is to check for a first parameter which has any (not necessarily all!) of the testing.TB methods for reporting failures. That is considered a valid alternative to Gomega.

There's now a potential false negative in the linter when passing such a function directly to gomega.Eventually/Consistently. That'll fail at runtime because gomega cannot call it, so such a false negative isn't too bad (fails reliably and obviously).

The warning message doesn't get changed because it would be confusing for most users to call out some vague alternative (vague because the linter has no details) that most users won't be able to use.

Fixes # (issue)

kubernetes/kubernetes#135664 (comment)

Type of change

  • New feature (non-breaking change which adds functionality)

How Has This Been Tested?

  • Added test case and related test data

Checklist:

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules
  • I ran make goimports
  • I ran golangci-lint

@nunnatsa

In Kubernetes' ktesting package the following assertion is valid:

    tCtx.Eventually(func(tCtx TContext)).Should(Succeed())

That works because tCtx.Eventually wraps the function such that failures
reported via tCtx.Error/Errorf/Fatal/Fatalf are visible to the matcher.

Without this change, the "Success matcher only support a single error value, or
function with Gomega as its first parameter" warning is triggered.

Instead of building in specific support for ktesting, the approach is to check
for a first parameter which has any (not necessarily all!) of the testing.TB
methods for reporting failures. That is considered a valid alternative to
Gomega.

There's now a potential false negative in the linter when passing such a
function directly to gomega.Eventually/Consistently. That'll fail at runtime
because gomega cannot call it, so such a false negative isn't too bad (fails
reliably and obviously).

The warning message doesn't get changed because it would be confusing for most
users to call out some vague alternative (vague because the linter has no
details) that most users won't be able to use.
@pohly pohly force-pushed the assertion-wrappers branch from 8a7cb7c to 191627f Compare December 17, 2025 10:12
@coveralls
Copy link
Collaborator

Pull Request Test Coverage Report for Build 20299229615

Details

  • 28 of 30 (93.33%) changed or added relevant lines in 2 files are covered.
  • 1 unchanged line in 1 file lost coverage.
  • Overall coverage increased (+0.04%) to 87.905%

Changes Missing Coverage Covered Lines Changed/Added Lines %
internal/expression/actual/asyncfuncarg.go 24 26 92.31%
Files with Coverage Reduction New Missed Lines %
internal/gomegainfo/gomegainfo.go 1 70.0%
Totals Coverage Status
Change from base Build 20220479481: 0.04%
Covered Lines: 2580
Relevant Lines: 2935

💛 - Coveralls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants