Skip to content

testing: prevent (*testing.F) methods from being called inside (*testing.F).Fuzz fn #48988

Closed

Description

@katiehockman

From #48884

func FuzzFoo(f *testing.F) {
	f.Logf("parent f.Logf")
	f.Fuzz(func(t *testing.T, n uint8) {
		f.Logf("child f.Logf %d", n) // I'm allowed to use f.Logf here? f.Fatalf panics.
		t.Logf("child t.Logf %d", n)
		if n%3 == 0 {
			t.Fatal("boom")
		}
	})
}

@mvdan:

child f.Logf is allowed and ends up being printed along with parent f.Logf. It is not allowed to call f.Fatalf from inside the fuzz function taking a *testing.T, so I think we should similarly disallow calling any testing.TB methods on the parent *testing.F, such as Logf. I actually used f.Logf instead of t.Logf by mistake, and was very confused why my log lines ended up in the wrong position in the resulting failure output.

Let's disallow calls like f.Logf inside the f.Fuzz function, and encourage t.Logf and the like instead.

/cc @golang/fuzzing

Activity

  1. added
    NeedsFixThe path to resolution is known, but the work has not been done.
    fuzzIssues related to native fuzzing support
    on Oct 14, 2021
  2. added this to the Go1.18 milestone on Oct 14, 2021
  3. self-assigned this
    on Oct 14, 2021
  4. gopherbot commented on Oct 15, 2021

    @gopherbot
    Contributor

    Change https://golang.org/cl/356151 mentions this issue: testing: don't allow f.Log/Logf inside f.Fuzz

  5. locked and limited conversation to collaborators on Jun 23, 2023
  6. added a commit that references this issue on Sep 19, 2024
    9820602
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeNeedsFixThe path to resolution is known, but the work has not been done.fuzzIssues related to native fuzzing support

    Type

    No type

    Projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions