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.
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
This addresses vague and misleading output when asserting on the
equality of two values of differing numeric types.
Example: assert.Equal(t, int64(123), int32(123))
Previously, the user would have received a vague message claiming that
123 != 123. Now the message will read "int64(123) != int32(123)".
Implemented new InEpsilon by calculating the relative error and
comparing it to the expected epsilon rather than calculating the
acceptable margin and using InDelta.
While doing so we got rid of the false failure when the actual value
was zero.
The NotNil assertion had an error in its handling of typed nil values.
This change makes use of the helper function isNil (used by the Nil
assertion). The helper function has correct handling of typed nil
values and when negated provides the expected semantics for
`assert.NotNil(t, x)`.
if x == nil {
assert.Fail(t, "is nil", x)
}
