suite: allow Suite methods to take *testing.T parameter

[grongor]

Summary

Allow suite methods to take *testing.T parameter (as normal tests do). This is BC, and we are already messing with reflection there, so no penalties either.

Changes

Extend allowed suite method signature to include optional *testing.T.
Fail with a friendly error when the signature doesn't match (before it panicked).

Motivation

There are many places where you need t, like for example for mocks and other testing libraries. And typing s.T() get's tedious after a while, and is completely avoidable at no cost :)

type MyTestSuite struct {
	suite.Suite
}

func (s *MyTestSuite) TestLorem(t *testing.T) {
	s.Same(t, s.T())

	mockA := mocks.NewMockA(t)
	mockB := mocks.NewMockB(t)
	mockIHaveTooManyMocks := mocks.NewMockMyLife()

	testStuff(mockA, mockB, mockIHaveTooManyMocks)
}

func (s *MyTestSuite) TestSimple() {
	s.NotEqual("this is", "backwards compatible")
}

[grongor]

Just a few days ago I saw this PR and though that it's a shame it didn't get merged, so...thank you for taking another look! 🙇 🚀

[dolmen]

I think we should go further and also allow *assert.Assert as an alternative version of the parameter, because there is a high chance that our assertions will be used.

[grongor]

Sure, could be useful :) But then:

• not everyone is using the assert package; I personally prefer require...so maybe both?
• we still need access to the *testing.T for stuff like test helpers, mock constructors,...

So to make this truly universal and flexible we'd need to compare the list of parameters with the "list of allowed values" (containing *testing.T, *assert.Assertions and *require.Assertions for now) in arbitrary order. It can be done and it wouldn't even be that difficult...It is a bit unorthodox/"not something you see every day", but on the other hand this is a lib for testing - a bit of magic is kinda expected.

If you want I can look into it ;) If you choose to keep it simple with "just the T", it's imo perfectly reasonable too :)

[brackendawson]

The panic on mis-matched signature can be resolved by #1665, this PR only addresses changing the signature change.

Changing the signature would conflict with #1109 if in the future we fix the pseudo-inheritance in suite.

Is s.T() arduous? Why are we adding a second way to access an interface that we have a defined way to access, this is not typical in Go.

Adding *assert.Assert as an optional argument as well as *testing.T; what about both? Would the order matter? This seems a little bit like like pretending Go has keyword args.

The suite package already suffers from an incompatibility with Parallel testing because suite employed a pseudo-inheritance structure. The assert package suffers from unclear argument type validation because the msgAndArgs ...interface{} argument mis-uses variadics to give each assertion pseudo-optional arguments. I'm not currently convinced that optional parameters is a good idea.

[brackendawson]

You've not updated the package documentation.