Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Consider adding a more comprehensive set of package-level assertions #49
The design of the current API is something like this:
Top level assertions
The most common assertions (80% of calls) have a top-level assertion in the
(as a side node, I think I will probably look at rewriting the failure message to replace
For the next common case (the next 15% most common calls), and for any "assertion" that should use
For anything else (the last 5%) a local comparison can be written to compare values
As a result of that design most projects should be primary calls to a top level assertion, with a small number of calls that use
That said, do you think there are other assertions that are common enough to be in the 80% use case?
Checking error values is potentially a lot more common, but there are so many different ways to do that. Error/ErrorContains are just fallbacks if there are no types, but many errors should either have their own type defined by an interface, or an
If there are comparisons that do end up being more common we should definitely add them as top level assertions. If there are comparisons that aren't provided by
What's the rationale for not including helper functions? I guess I don't see the point in forcing users to import
Also, regarding the list of assertion expressions, I would suggest that
Here are the top ~20 stretchr/assert helper functions across all github repos in my $GOPATH:
A couple reasons. One is that golang provides two ways to fail a test (Fail, FailNow). I think
In these cases it can be beneficial to use
The convenience function can only use one of the failure functions (FailNow) or there would have to be duplicate functions to handle both. I'd like to avoid the duplication, so there will always be a need to use some comparisons from
A second reason is that I'd like the keep the
Finally, it's easier to add something than to remove it. Using
I hope that helps explain the rational. I also hope that the extra import isn't a significant barrier. In many cases
Thanks for asking these questions. I've been meaning to write down the rational for this design, and these questions help me organize my arguments.
Less obvious, I think I agree, but maybe that's because we're used to testify? A big influence for this library is pytest which did a lot of things differently from the traditional junit style assertions/framework. In pytest you write all assertions as
I think it will become more intuitive, and if not it's never to late to add it.
I'm not sure if I agree about explicit.
I completely agree, this is something I need to fix. I opened #50 to track it. I think it should be easy to translate
This is awesome, thanks for these numbers! I'd like to get these numbers for a few more go projects to see how they compare. If it turns out there are other common assertions then I'm definitely happy to add them as convenience functions.
Looking at your numbers, 80% would be the top 5 assertions, which are potentially entirely covered already by Assert/Equal (but will probably require DeepEqual) as well. I would need to look into why
Ease of adoption is one of my main concerns. However, if we were to just copy the interface I think there would be very little reason to use
I would rather address this problem with an automated migration tool, see #36. It parses AST and replaces testify calls with new AST for
There's more polish that could be added, but that can be added over time.
Just to clarify: this isn't just my projects, this is all projects I have ever downloaded transitively or otherwise with
What are your problems with the public interface for testify?
My two biggest issues with testify are that diffs often don't show the actual differing entries, just pointer addresses (which is completely useless), and that
Anyway, it sounds like you're happy to keep your current API and are trying to attract users who don't really like the testify API. Personally, I like it, so I'll stick with it.
The issues I see with the interface are: test-go/testify#13
Also not in that list:
Once all those API changes are made I think the end result will be what ends up in
I fully expect to add more package level convenience functions, but I'd rather wait to see what actually gets used frequently with the new API.
I've used pytest extensively and it is excellent... I was about to point out how pytest differs in that it reflects the assertion expression, and that made me realise that gotestyourself does the same thing...
However, I had absolutely no idea that gotestyourself did this, as it isn't mentioned anywhere in the README or godocs (that I could find)... this seems like the key differentiator between gotestyourself and testify, why isn't it mentioned anywhere?
The rest of this conversation now actually makes sense to me.
This was referenced
Feb 13, 2018
Full list of the current asserts: https://godoc.org/github.com/gotestyourself/gotestyourself/assert#pkg-index
Going to close this issue, but if there are specific cases that are commonly used and aren't covered I'd still like to hear about it.