Helper() in the standard Go runtime fetches a stack trace from the
runtime, so is slow for calls that are made many times.
Helper() only makes a difference if the call throws an error, so move
it after the test in straightforward cases.
It is not very helpful to print that the lengths differ when an
assertion fails, since that does not reveal what the cause of the issue
might be.
Let's print which elements are extra in each list, that should convey
the relevant information to the user. Also use spew to format the
objects, similar to what Equal does, to make the output more readable.
If asserting an error contained in a string, includeElement will fail
but Contains will confusingly print both values as strings, which can
look like a testify problem instead of an assertion failure.
If you were comparing values which when formatted were longer than about 64k then the actual, expected and diff messages were not printed to the console.
`spew`'s default formatter will call `String()` or `Error()` in structs
that implement the `fmt.Stringer` or `error` interfaces. Depending on
the implementation of those, the diff can become quite useless to read
(see the example struct I used for the test case in this commit).
This changes `spew`'s configuration to `DisableMethods` so that it will
always use it's own pretty printer. This makes testing structs less
surprising and generally more useful, without tying the tests to the
implementation of `String()` (the user here can always chose to
`require.Equal(a.String(), b.String())` if testing those is important to
them.
# What
Add `PanicsWithError` that behaves like `PanicsWithValue` but requires
the value to be an `error` and compares an error string against the
error in the same fashion as `EqualError`.
# Why
`PanicsWithValue` is very useful with the value that will panic is a
basic type that can be easily defined in a test, but is less useful for
validating an error because error values may not be easily recreated in
a test to exactly match the error that will be generated in the moment.
This can be because an error will contain fields that aren't exported
and the test may not be able to define the exact error. Most of the time
testing error objects just testing the string is sufficient. This
concept is already supported by this module in the existing `EqualError`
function.
* Added NotSame test for the assert package
* Added NotSame test for the require package
* Included formatted variants of NotSame for both assert and require
Use Go 1.9 t.Helper() to remove testify from the output of the tests and
stop using `\r` to try to overwrite the output.
This means in Go 1.7 and Go 1.8 testify will appear as failing the test.
HTTP assertions were missing the trailing `msgAndArgs ...interface{}`,
making it inconsistent with the rest of the assertions and resulting in
incorrect `*f` wrappers.
Fixes#528
An assertion that compares the elements of the slices/arrays disregarding the order,
i.e. it checks whether each element in the first slice/array appears the same number of times in it
as in the second slice/array.
This name seemed like it would be easy to find.
Possible alternatives for the name:
- ContainsSameElements
- IsPermutation (C++: http://en.cppreference.com/w/cpp/algorithm/is_permutation)
- MatchArray (rspec: http://www.rubydoc.info/github/rspec/rspec-expectations/RSpec/Matchers:match_array)
- EqualSorted
- Other ideas?
This implementaiton is O(N^2), while sorting both lists first would be O(nlogn).
However, this one doesn't need to copy the lists, so it is simpler and doesn't require additional
memory and time for the copies.
I realize this was deemed as out of scope
https://github.com/stretchr/testify/issues/275
but I decided to give it a shot as I needed it also.
The assertion function was simply returning false, which doesn't actually fail a test.
An example test that should have failed but doesn't:
func TestNotSubset(t *testing.T) {
assert.NotSubset(t, []string{"x"}, nil)
}
Make `Empty` work against any struct and custom types, by replacing
explicit zero value comparisons with a `DeepEqual` comparison with
the type's `reflect.ZeroValue`.
Previous implementation depended on tab alignment. This worked
when the output was not prepended with anything, but would break
if the output was prepended with further spaces (which can occur
in environments like IntelliJ test runners). This commit fixes it
so that the output is always aligned logically.
Fixes#83
- NoError prints the error message on the next line, unquoted, which makes multiline error messages much clearer. Sample of an error message which includes a multiline stacktrace:
Error: Received unexpected error:
Hi!
/Volumes/Pouch/Users/russegan/dev/go/src/gitlab.protectv.local/ncryptify/client.git/client_test.go:27 (0x75c8c)
TestNew: assert.NoError(merry.New("Hi!"), "with message")
/usr/local/Cellar/go/1.7rc1/libexec/src/testing/testing.go:610 (0x70a01)
tRunner: fn(t)
/usr/local/Cellar/go/1.7rc1/libexec/src/runtime/asm_amd64.s:2086 (0x5d131)
goexit: BYTE $0x90 // NOP
Messages: with message
- Error,NoError,and EqualError now don’t inline the user’s extra messages. user’s messages are printed in the “Messages:” section, as with all other assertions.
- EqualError now avoids isNil(), mirroring the changes already made to Error and NoError.
- Equal, EqualValues, and EqualError now print the expected and actual values each on a newline, aligned vertically, which makes it easier for a human to visually detect the differences. Examples:
Error: Error message not equal:
expected: ”no failure"
recieved: “failure"
Messages: with message
Error: Not equal:
"high" (expected)
"low" (actual)
Messages: with message
- EqualValues uses the same value formatting and diff output as Equal for consistency