New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
assert/require.Len doesn't print anything if the slice is too long #1525
Comments
The easiest workaround for now seems to be: package tester_test
import (
"testing"
"github.com/stretchr/testify/require"
)
func TestVeryLongSlice(t *testing.T) {
var bigSlice []string
for i := 0; i < 20000; i++ {
bigSlice = append(bigSlice, "hello")
}
expected := 10
require.Len(
t,
bigSlice,
expected,
"Should have %d item(s), but has %d",
expected,
len(bigSlice),
)
} |
We use a scanner to get the text which should go there line by line (it can be multiline) to indent each line until after the field name: Lines 304 to 313 in 7caada5
This mishandles the We need to think of a thing to do about very long lines in this code. We should also probably not produce such a long line from |
That sounds good to me. Personally I'd even be happy for the contents of the slice not to be printed at all, but I suppose this output can be useful for shorter slices when troubleshooting why a test is failing. Cheers |
Hello |
Thanks, yep I'm using this already, but I think my point was more around the inconsistency of the API and how that particular function feels odd in the context of the rest. Of course I appreciate that this would be a breaking change but just thought I'd bring it up for consideration in case a major new version of testify was being planned. Cheers |
The argument order is covered by #146. Let's keep this issue about the missing message. |
… messages As pointed out in stretchr#1525, when the assertion message is too long, it gets completely truncated in the final output. This is because, `bufio.Scanner.Scan()` has a default `MaxScanTokenSize` set to `65536` characters (64 * 1024). The `Scan()` function return false whenever the line being scanned exceeds that max limit. This leads to the final assertion message being truncated. This commit fixes that by manually setting the internal scan buffer size to `len(message) + 1` to make sure that above scenario never occurs. Fixes stretchr#1525
I've raised a PR that will make sure that the
Agreed. But regardless of the call we take about displaying long messages, I think this fix will be useful. |
Hey there, I encountered this when attempting to use
require.Len
as shown below.Output of test:
I haven't quite figured out why this happens, although I can imagine the output would be impractically long anyway. Worst of all, the main assertion message is not displayed which is quite confusing (especially to someone new using the library, like me 😄).
Personally, I think that it would be best not to display the slice at all for the
Len
function, and instead just display:However, I suspect my view on that may not be what some people want. The reason I think it is unwise to print the slice in any form, is that typically when many people are testing for the length of a slice, they may be comparing to a relatively large slice of items (e.g. the output of a mocked API call or similar).
An additional point that I believe has been discussed before is the inconsistency with argument ordering for the
Len
function which takes theactual
first andexpected
second.Cheers
Fotis
The text was updated successfully, but these errors were encountered: