suite.Run: validate Test* methods signature

[Barugoo]

Summary

Added panic in suite.Run if Test* method has args or returning values

P.S. This is my first ever opensource contribution, so I'm very open to any code logic/styling criticism!

Changes

• Now, before calling Suite method there's an additional check for signature correctness: it should have not more than 1 arg (receiver) and 0 returning values
• If Test* method signature fails the above check test panics with the message: testify: suite method <MethodName> shouldn't have any arguments or returning values
• Added test cases for incorrect signature variants

Motivation

As @wvell mentioned in issue #1508 currently, suite.Run returns an ambiguous error when executing with instance of Suite that has incorrect Test* methods signatures.

Related issues

Closes #1508

[Barugoo]

Not sure about using panic here tho, seems appropriate to me, but i will appreciate if you take a look @dolmen

[wvell]

Isn't it better to use t.Error(msg)? Then you can directly see the TestMethod violating the contract. I find panic always quite hard to read.

[Barugoo]

@wvell the motivation to add panic here instead of t.Error is the source of this condition. I.e. It is not the tested code returning unexpected result, but rather the programmer who messed up the signature of the Test* method itself. In that case panic is more fitting IMHO

[wvell]

Yeah fair point, I just hate reading panics.

Thanks for putting in the work.

[dolmen]

While I'm a strong advocate of panic to catch programmer's mistake, I think a panic is not appropriate in this case as the stack trace will not be useful to the user.

Instead Run is being called with *testing.T, so let's just use t.Fatal (or t.Fatalf) to report the issue.

However, the main problem with this implementation is that this check must be done much much earlier, line 151, just after the successful call to methodFilter.

[dolmen]

While I'm a strong advocate of panic to catch programmer's mistake, I think a panic is not appropriate in this case as the stack trace will not be useful to the user.

Instead Run is being called with *testing.T, so let's just use t.Fatal (or t.Fatalf) to report the issue.

However, the main problem with this implementation is that this check must be done much much earlier, line 151, just after the successful call to methodFilter.