This helper is used to capture the testing.TB interface, and compare
the log output with the expected output.
This is useful for testing and refactoring purposes.
This commit improves the helper by displaying:
- the captured and expected outputs on a newline.
- the special characters in the captured output, such as newlines and tabs.
Both help with readability.
Here is an example of the output before and after the change:
Before:
assertions_test.go:3422: Logged Error: Should be in error chain
expected: *assert.customError
in chain: "EOF" (*errors.errorString)
assertions_test.go:3422: Should log Error: Should be in error chain:
expected: *assert.customError
in chain: "EOF" (*errors.errorString)
After:
assertions_test.go:3394: Recorded Error: "Should be in error chain:\nexpected: *assert.customError\nin chain: \"EOF\" (*errors.errorString)\n"
assertions_test.go:3394: Expected Error: "Should be in error chain\nexpected: *assert.customError\nin chain: \"EOF\" (*errors.errorString)"
The new format helps to identify the differences:
- the missing colon after "Should be in error chain"
- the extra newline in the captured output
Note: I spent 10 minutes on this change, because I lost 10 minutes in
finding the differences between the captured and expected output on a
refactoring I was doing.
In package assert, fix TestFileExists, TestNoFileExists, TestDirExists, TestNoDirExists
to be able to run in parallel:
- use t.TempDir() as the storage location for temporary created
symlinks. This also allows the cleanup of that storage to be
automatically handled by "go test". testing.T.TempDir is available
since go1.15.
- enable parallel testing on each test
Extend TestNotEqualValues to also test EqualValues by leveraging the fact
that they are inverse functions. The same test cases are used to verify
that EqualValues returns the opposite result of NotEqualValues.
This change ensures both success and failure paths are tested for
EqualValues, covering the error formatting and failure reporting code
that was previously untested.
Coverage improvement:
- EqualValues: 57.1% → 100.0%
- Overall package: 68.4% → 68.5%
The test function was renamed to TestEqualValuesAndNotEqualValues to
reflect its dual purpose while maintaining all existing test logic.
Co-Authored-By: sketch <hello@sketch.dev>
Change-ID: s30d4192b08186d88k
Simplify isEmptyValue (used by assert.Empty) by checking early if the
value is the zero value of the type using reflect.Value.IsZero
(available since Go 1.13, so after the initial assert.Empty implementation).
isEmpty is now faster.
go test -bench Benchmark_isEmpty
goos: darwin
goarch: arm64
pkg: github.com/stretchr/testify/assert
cpu: Apple M2
Before:
Benchmark_isEmpty-8 15841243 77.27 ns/op 8 B/op 1 allocs/op
After
Benchmark_isEmpty-8 50665512 21.08 ns/op 0 B/op 0 allocs/op
Add a benchmark that shows that isEmpty does memory allocations.
$ go test -bench Benchmark_isEmpty
goos: darwin
goarch: arm64
pkg: github.com/stretchr/testify/assert
cpu: Apple M2
Benchmark_isEmpty-8 15074973 76.73 ns/op 8 B/op 1 allocs/op
We can do better!
Document the assert.Empty rules more comprehensively. This exposes our
quirks to the user to avoid wrong expectations.
Add many many many more test cases that document edges cases and will allow
to catch breaking changes and avoid regressions.
Enable parallel testing for almost all tests in packages 'assert' and
'require' by calling t.Parallel() as the first line of the test.
A few tests are incompatible and will be fixed separately. They are
marked with a FIXME.
Incompatible tests: TestFileExists, TestNoFileExists, TestDirExists,
TestNoDirExists.
Before:
$ go test -count=10 ./assert ./require
ok github.com/stretchr/testify/assert 7.575s
ok github.com/stretchr/testify/require 1.501s
After:
$ go test -count=10 ./assert ./require
ok github.com/stretchr/testify/assert 1.703s
ok github.com/stretchr/testify/require 1.245s
Only the tests are updated, code is unchanged.
Previously, the tests were checking only the result of the asserter.
Using captureTestingT helper allows to check the error message
Add the `IsNotType` assertion, which is the inverse
of the existing `IsType` assertion. It allows users to assert that an
object is not of a specific type.
Additionally, minor documentation improvements were made.
## Summary
This PR adds a new assertion function, `IsNotType`, to the
`testify/assert` package. It complements the existing `IsType` function
by providing a way to assert that an object is not of a specific type.
## Changes
* Added the `IsNotType` function to the `assert` package.
* Wrote unit tests for `IsNotType` to ensure correctness.
* Updated documentation to include examples and usage for `IsNotType`.
## Motivation
The `testify/assert` package already provides an `IsType` function to
check if an object is of a specific type. However, there was no built-in
way to assert that an object is **not** of a specific type. This PR
addresses that gap by introducing the `IsNotType` function, improving
the library's completeness and usability.
## Example usage
```go
assert.IsNotType(t, &MyStruct{}, actualObject)
```
## Related issues
_N/A_
Before:
Should be in error chain:
expected: *assert.customError
in chain:
After:
An error is expected but got nil.
expected: *assert.customError
The message `An error is expected but got nil.` is the one already
reported by `assert.Error`
