You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
everything is duplicated as Foo and Foof, and essentially duplicated again in require (since the code is generated this is more of an issue for users and less for maintenance, also less code generation wouldn't hurt).
HTTP and JSON assertions belong in a separate package for testing http requests
lots of confusing overlap (Equal, vs Exactly, Zero/Nil/Empty/Len(x, 0), InDelta/InEpsilon)
unnecessary assertions (Fail, FailNow, True, and False provide nothing over the standard testing.T, NotPanics is effectively a no-op)
inconsistent parameter placement (Contains/Len/EqualError all accept the expected value as the second arg, but most other assertions accept the expected as the first)
require behaves the way most people would expect assert to behave. assert is more of a "check"
In addition to fixing these issues, some of the benefits to this design are:
now that t.Helper() exists there's no need to calculate line numbers, so all that code is removed
extensible assertions. users can write custom comparisons (func() (bool, string)) that return success/failure message. This also removes the need for code generation, and still supports both Fail and FailNow
more type safe asserts (Equal uses actual equality (==), Compare uses go-cmp for comparing complex types)
Assert() supports booleans as well as Comparison, so trivial compares of booleans, or x != nil can be done inline, and the source is printed as the failure message(ex: "assertion failed: x != nil is false")
I'm writing a tool that translates testify.Assert into assert.Assert() using go/ast rewriting, to make it trivial to migrate a project to the new interface.
Since you are spending time on this fork, and looking for maintainers I'm wondering if our goals are aligned and we might be able to share some work.
The text was updated successfully, but these errors were encountered:
Hello, I'm wondering if you are planning on fixing some of the problems with the package interface.
I think some of the main problems are:
Foo
andFoof
, and essentially duplicated again inrequire
(since the code is generated this is more of an issue for users and less for maintenance, also less code generation wouldn't hurt).HTTP
andJSON
assertions belong in a separate package for testing http requestsrequire
behaves the way most people would expectassert
to behave.assert
is more of a "check"Equal
usesreflect.DeepEqual()
which has many shortcomings, which can be fixed by using https://godoc.org/github.com/google/go-cmp/cmpI have been working on a library which I believe fixes all of these issues: gotestyourself/gotest.tools#34
In addition to fixing these issues, some of the benefits to this design are:
t.Helper()
exists there's no need to calculate line numbers, so all that code is removedfunc() (bool, string)
) that return success/failure message. This also removes the need for code generation, and still supports both Fail and FailNowAssert()
supports booleans as well as Comparison, so trivial compares of booleans, orx != nil
can be done inline, and the source is printed as the failure message(ex: "assertion failed: x != nil is false")I'm writing a tool that translates
testify.Assert
intoassert.Assert()
usinggo/ast
rewriting, to make it trivial to migrate a project to the new interface.Since you are spending time on this fork, and looking for maintainers I'm wondering if our goals are aligned and we might be able to share some work.
The text was updated successfully, but these errors were encountered: