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.