Skip to content

Conversation

@ubunatic
Copy link
Owner

Summary

Catch all possible results, incl. panics, that can happen to a condition inside the Eventually implementation and use a corresponding error message.

This Demo PR in my contrib repo is an alternative implementation to stretchr#1809.

Changes

  • use result strings
  • add + handle condition panic with an extra t.Errorf
  • return "Condition " for timeout, test failure, and panic separately
  • Extend go test test to better analyze the failed test logs for the testing.T log

Motivation

  • Use very explicit error handling to show the developer what was actually going wrong.

Related issues

}

func (c *CollectT) failed() bool {
func (c *CollectT) Failed() bool {
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be OK to expose, since it is a very std. method and provides utility in tests where you want to reason on the collect status.

If not desired, I can track tests errors in another variable.
See new(assert.CollectT) further below, where I use it.

select {
case <-timer.C:
return Fail(t, "Condition never satisfied", msgAndArgs...)
return Fail(t, ResultTimeout, msgAndArgs...)
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same message as before

// We can stop here and now, and mark test as finally failed with
// the same error message as the timeout case.
return Fail(t, "Condition never satisfied", msgAndArgs...)
return FailNow(t, v, msgAndArgs...)
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

two new messages, since these are two new ways of aborting the eventually


func TestFailInsideEventuallyViaCommandLine(t *testing.T) {
t.Setenv("TestFailInsideEventually", "1")
cmd := exec.Command("go", "test", "-v", "-race", "-count=1", "-run", "^TestFailInsideEventually$")
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another clean alternative would be to store the log output from the always failing test as test fixure. And only analyze the fixure here.

The fixure can be create are part of the code gen.

I am not sure we can easily extend MockT to reproduce this.

@ubunatic ubunatic changed the title DEMO: Handle panics and make condition result explicit IDEA: Handle panics and make condition result explicit Oct 15, 2025
@ubunatic ubunatic force-pushed the eventually-clean-exit-test branch from 2774c83 to 80bd5f0 Compare October 16, 2025 10:46
@ubunatic ubunatic closed this Oct 19, 2025
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