Better comments/naming in ExpectPanic()

[liquidgecka]

This changes the variable name from err to iface and updates the comment
to better address the use cases for this function.

[philpennock]

LG. I wonder if it's worth having testlib sentinel values, such as AnyPanic, so if you call:

tt.ExpectPanic(myfunc, testlib.AnyPanic, "myfunc should panic with something (don't care what)")

then the testlib handles it?

Or should it be ExpectPanicPredicate() for that scenario, where the second parameter is a function used to validate the interface, and can just be something which always returns true if someone really doesn't care?

[liquidgecka]

I mean its always possible to make the second argument accept a specific function footprint that does the validation as well. My initial stab at this was pretty simple because its fairly easy to write a panic function anyway..

def func TestX(t *testing.T) {
    T := testlib.NewT(t)
    defer T.Finish()
    defer func() {
        i := recover()
        T.NotEqual(i, nil)
        // T.Equal(i, xyz)
    }()
    // Do stuff
}

I was trying to handle the most common case for panics (assertions for code quality checking) and leaving the complex stuff to the caller since it will be more readable that way. I mean, if your implementing a function anyways the above is likely more readable anyway.

What do you think?

[coveralls]

Coverage remained the same at 100.0% when pulling 9b7d3b5 on brady/add_expect_panic into 561e6b2 on master.

[philpennock]

I think the "don't care what the panic is" sentinel value is probably worth implementing, anything beyond that is YAGNI territory. But approved as-is.