Do you need to use the suite assert/require helper methods or suite.Run, or can you continue using the functions and t.Run() instead?

[chancez]

I've got a bunch of code I think could benefit from using the suite package, but I loath updating everything that's currently using assert.Equal()/require.NoError (etc) to suite.Equal, or suite.Require().NoError().

Another case I have is I already had some reuse going on with some helper funcs that just took a testing.T and called t.Run(), and like the UX of t.Run more than suite.Run, and wondering if I can do t := suite.T(); t.Run(...) instead?

Are there any trade-offs to be concerned with by not using the suite methods, and only using the suite to handle common test setup and such?

[hemflit]

If you don't actively change the suite.Suite type's relevant behaviour (overriding methods like Run or overwriting mySuite.Assertions) then there should be no downsides other than what comes from your test code being somewhat unidiomatic, and possibly slightly more error-prone due to the burden of ensuring it's always using the right instance of T.

Another case I have is I already had some reuse going on with some helper funcs that just took a testing.T and called t.Run(), and like the UX of t.Run more than suite.Run, and wondering if I can do t := suite.T(); t.Run(...) instead?

Yes, as long as the subtest is using the T it gets passed in and not the parent one that got stored in the variable, and you're fine with not running (Setup|Teardown)SubTest. And no Parallel, of course.

[tamish560]

To add to what hemflit said, you can absolutely mix assert.Equal() / require.NoError() with the suite package. The suite's assert and require methods are just convenience wrappers that automatically bind the test's *testing.T so you don't have to pass it each time. Functionally equivalent.

For t.Run() vs suite.Run(): you can use suite.T().Run() just fine. The suite doesn't override the behavior of t.Run(), it just provides hooks (SetupTest, TearDownTest, BeforeTest, AfterTest) that fire around the suite's own test methods. If you call t.Run() directly inside a suite test method, those hooks won't fire for sub-tests created that way, which might surprise you if you're relying on them.

The practical tradeoff:

• Use suite.Run() for tests that need the suite lifecycle hooks (setup/teardown per test)
• Use t.Run() for plain sub-tests that don't need suite lifecycle management

Mixing both is fine, just be aware of which lifecycle hooks you're opting out of when you use t.Run() directly.