README
The testify/v2 we wanted
Motivation
From the maintainers of testify, it looks like a v2 is coming up, but they’ll do it at their own pace.
We like all the principles they put forward to build this v2. See discussion about v2
However, at go-openapi we would like to address the well-known issues in testify with different priorities.
- We want first to remove all external dependencies.
For all our libraries and generated test code we don’t want test dependencies to drill farther than
import github.com/go-openapi/testify/v2, but on some specific (and controlled) occasions.In this fork, all external stuff is either internalized (
go-spew,difflib), removed (mocks,suite,http) or specifically enabled by importing a specific module (github.com/go-openapi/testify/v2/enable/yaml).
- Make it easy to maintain and extend.
For go-openapi, testify should just be yet another part of our toolkit. We need it to work, be easily adaptable to our needs and not divert our development effort away from our other repos. This big refactor is an investment that has to pay off.
- We want to pare down some of the chrome that has been added over the years
The
go-openapilibraries and thego-swaggerproject make a rather limited use of the vast API provided bytestify.With this first version of the fork, we have removed
mocksandsuite, which we don’t use. They might be added later on, with better controlled dependencies.In the forthcoming maintenance of this fork, much of the “chrome” or “ambiguous” API will be pared down. There is no commitment yet on the stability of the API.
Chrome would be added later: we have the “enable” packages just for that.
- We hope that this endeavor will help the original project with a live-drill of what a v2 could look like. We are always happy to discuss with people who face the same problems as we do: avoid breaking changes, APIs that became bloated over a decade or so, uncontrolled dependencies, conflicting demands from users etc.
The approach with this fork
This fork targets go1.24.
- zero external dependencies by default
- extra features (and dependencies) are opt-in
- modernized code base
- simplified maintenance
- can add or remove assertions with ease
- mitigated API bloat with comprehensive domain-indexed documentation
- can leverage generics without backward compatibility concerns
The approach will be selective and pragmatic rather than comprehensive:
- Targeted improvements where generics provide clear value without compromising existing functionality
- Focus on eliminating anti-patterns like dummy value instantiation in
IsType(see #1805) - Preserve reflection-based flexibility for comparing complex types rather than forcing everything through generic constraints
- Careful constraint design to ensure type safety without being overly restrictive or permissive
The goal is to enhance type safety and developer experience where it matters most, while maintaining the flexibility that makes testify useful for real-world testing scenarios.
Breaking changes from v1
YAMLEqpanics by default: must enable the feature with an additional blank import- deprecated types and methods have been removed
- removed the
suite,mocksandhttppackages - replaced internal utility package
_codegenbycodegen
Other (non-breaking) changes
- added
JSONEqBytes - adapted & merged fixes: see ROADMAP.
Usage at go-openapi
At this moment, we have identified the following usage in our tools. This API shall remain stable. Currently, there are no guarantees about the entry points not in this list.