Introduce a standard `Fail` method about testify HOT 8 CLOSED

see also #1

from testify.

Difficult to do as what is printed is different for most failures.

Sent from my iPhone

On Nov 21, 2012, at 7:36 AM, matryer [email protected] wrote:

    t.Errorf("\r%s\r\tLocation:\t%s\n\r\tError:\t\tShould be true\n\r\tMessages:\t%s\n\r", getWhitespaceString(), CallerInfo(), message)

Put all of these into one place.

—
Reply to this email directly or view it on GitHub.

from testify.

Why not:

Fail(t *testing.T, failureMessage, messageAndArgs ...interface{}) bool {
  // just write this out to the `t`
  // the calling functions are responsible for writing the meaningful failureMessage
}

from testify.

NOTE: it should be a public method too... to allow people to just Fail in their test code.

assert.Fail(t, "This shouldn't happen")

from testify.

What is the goal? I don't see how this would result in less code in the methods?

Then again, I just woke up and I'm not quite functional.

On Nov 21, 2012, at 8:13 AM, matryer [email protected] wrote:

Why not:

Fail(t *testing.T, failureMessage, messageAndArgs ...interface{}) bool {
// just write this out to the t
// the calling functions are responsible for writing the meaningful failureMessage
}

—
Reply to this email directly or view it on GitHub.

from testify.

It provides:

• People will be able to directly Fail using assert.Fail (this is useful for advanced code or if people want to write their own assertion methods - like AssertContextHasDatabaseSession(t, context))
• We would have ONE place where we can change the output of failures, so if we change it (i.e. decide that we need to prefix the filename so it's double-clickable in Sublime) we can do so easily.
• It is consistent with other assertion/testing packages that offer a general fail method
• If we decide in the future to output a machine readable result (i.e. Something went wrong (if they set a specific flag) then we would only do so in one place.

What is the goal? I don't see how this would result in less code in the methods?

Then again, I just woke up and I'm not quite functional.

On Nov 21, 2012, at 8:13 AM, matryer [email protected] wrote:

Why not:

Fail(t *testing.T, failureMessage, messageAndArgs ...interface{}) bool {
// just write this out to the t
// the calling functions are responsible for writing the meaningful failureMessage
}

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

from testify.

Sounds good to me.

On Nov 21, 2012, at 8:30 AM, matryer [email protected] wrote:

It provides:

• People will be able to directly Fail using assert.Fail (this is useful for advanced code or if people want to write their own assertion methods - like AssertContextHasDatabaseSession(t, context))
• We would have ONE place where we can change the output of failures, so if we change it (i.e. decide that we need to prefix the filename so it's double-clickable in Sublime) we can do so easily.
• It is consistent with other assertion/testing packages that offer a general fail method
• If we decide in the future to output a machine readable result (i.e. Something went wrong (if they set a specific flag) then we would only do so in one place.

What is the goal? I don't see how this would result in less code in the methods?

Then again, I just woke up and I'm not quite functional.

On Nov 21, 2012, at 8:13 AM, matryer [email protected] wrote:

Why not:

Fail(t *testing.T, failureMessage, messageAndArgs ...interface{}) bool {
// just write this out to the t
// the calling functions are responsible for writing the meaningful failureMessage
}

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

from testify.

This was done ages ago, it seems.

from testify.