handle t.Parallel in fixtures

[IlyasYOY]

Thanks for the linter – it’s great.

I wanted to share a use‑case that the current checks don’t cover yet, and suggest a first‑iteration implementation.

Example usage

func TestFoo(t *testing.T) {
    sut := newSUT(t)

    got := sut.Do()

    assert.NotNil(t, got)
}

where the helper looks like:

func newSUT(t *testing.T) *sut {
    t.Helper()
    t.Parallel()

    return &sut{
        // something...
    }
}

In this pattern the test creates a fixture (newSUT) that calls t.Parallel. The linter should be able to detect such cases and ignore them.

Proposed first‑iteration algorithm

1. Find all calls to unexported functions from a test (*_test.go).
2. For each such function, check whether it has a *testing.T (or testing.T) parameter.
3. Scan the function body for a call to t.Parallel().
4. Recursively analyze any nested helper calls.

This should be relatively straightforward to implement and would catch a large portion of the current false‑positives.

Future extensions

• Detect similar patterns in functions imported from other packages.
• Handle additional testing utilities, etc.

Why this matters

Adding this check would directly address the issue discussed in #49, especially since these helper functions are often used in fixtures.

I’d be happy to contribute an implementation if that sounds useful—just let me know the best way to get started!

[IlyasYOY]

Here is my patch for test that fails:

diff --git a/pkg/paralleltest/testdata/src/t/t_test.go b/pkg/paralleltest/testdata/src/t/t_test.go
index 3780943..7e8e7f3 100644
--- a/pkg/paralleltest/testdata/src/t/t_test.go
+++ b/pkg/paralleltest/testdata/src/t/t_test.go
@@ -356,3 +356,11 @@ func builderWithoutParallel() func(t *testing.T) {
 		fmt.Println("test from builder without parallel")
 	}
 }
+
+func TestUsingHelper(t *testing.T) {
+	testHelperWithParallel(t)
+}
+
+func testHelperWithParallel(t *testing.T) {
+	t.Parallel()
+}

Here is the failure message:

/Users/ilyasyoy/go/pkg/mod/golang.org/x/tools@v0.31.0/go/analysis/analysistest/analysistest.go:630: t/t_test.go|360 col 1| unexpected diagnostic: Function TestUsingHelper missing the call to method parallel

[IlyasYOY]

I've added a commit with tests. I would be glad to paint them green 😄

[kunwardeep]

Your test will work, but typically, t.Parallel() is called directly at the beginning of the TestXxx function, not within a setup helper like newSUT.

While calling it inside newSUT does enable parallel execution for TestFoo, the standard and most readable practice is:

func TestFoo(t *testing.T) {
    t.Parallel() // Call Parallel here

    sut := newSUT(t) 
    // ... rest of the test
}

func newSUT(t *testing.T) *sut {
    t.Helper() // Only Helper is needed here
    // ... setup logic
}

Developers usually put t.Parallel() as the very first line of the TestXxx function. This is for clarity and readability: it makes it immediately obvious to anyone reading the code that the test is designed to run in parallel, without having to dive into a setup helper function.

Any particular reason you are choosing to put the parallel method in the helper newSUT?

[IlyasYOY]

@kunwardeep I agree that putting t.Parallel at the beginning of the function might help spot the parallel tests visually.

On the other hand, we have to put t.Parallel at the beginning of every function. Usually I have a helper function to set up the system under test. The system itself is safe to use if instantiated using this helper. I can use this knowledge to mark a test as parallel.

More than that, I faced the problem:

• I have t.Parallel in a helper,
• I have a linter complaint,
• I go and put t.Parallel,
• I get an error because we cannot mark a test parallel multiple times.

It makes me remove t.Parallel from all helpers and add it manually as you say. This might not be intuitive (as it was for me).

---

I hope this explains why it's a good idea, at least from my point of view.

PS. I guess my PR is "stale" now. Seems like: #58 solves the same problem and more.