Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Implement action test suite helper #1139
Implement action test suite helper #1139
Changes from 11 commits
9e53841
fb5d9a7
18ffdf2
f189b56
504df82
c07bca0
adcf1ae
48af784
566fff4
4f860f1
96a8d0a
900cf09
41c7e18
85b254b
5a11a97
5fc6d05
5dac07b
25f23e2
94c5cf0
0fe76f1
8e5bc5b
5b5ff1c
c31613d
5197db3
2bb3973
b3ed3b5
dbc4076
45383c3
8cd0738
c9c9dea
160137b
b2be701
3c266e6
9055d39
7b55c6f
86f8f46
ddd5084
658b810
0cf9190
c97b9b9
0286e57
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
err and output should be mutually exclusive but it doesn't hurt to still check it at the end, even if
err != nil
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now using
errors.Is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You won't reach the output check because you're using
require
; swapping toassert
will uset.Errorf()
under the hood instead oft.Fatalf()
, but I don't think you should.I think it does actually, even if very minor, because it forces every error path to have a strict return value (presumably
nil
) when in reality the value is undefined.More context should anyone be interested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Long live a healthy combination of
assert
andrequire
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should keep using
require
, otherwise the test author needs to keep thinking about which failures will cause the test to fail vs where the test can continue.If the test fails, then debugging is needed and often the first point of unexpected behavior is what is most useful for debugging.
Additionally, require is more concise than
if err != nil
style checks, which is needed to uset.Fatal
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's actually the point. It avoids whack-a-mole fixes where you get partial information about problems. The test author really should be thinking about that because they're the one person with the greatest insight.
My rule of thumb is that errors use
require
because that almost certainly guarantees that all other returned values are incorrect. Incorrectactual
orgot
values, however, are typically more suited toassert
.require
is equivalent tot.Fatal
so there's no need for theerr != nil
check. The alternative isassert
, which is equivalent tot.Error
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would we know that we have a problem of partial information? I haven't heard folks complaining about it, but maybe we're just inured...
I think that in most cases the use of testify with its rich set of assertions (and correspondingly useful contextual output on failure) obviates most of the concerns expressed in the style guide. Where those assertions aren't sufficient, we're always free to implement custom checks.
If we did decide to mix assert and require, there are cases where a group of assertion calls would need a subsequent check to ensure that any of the assertion calls failing would subsequently fail the test e.g.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as https://github.com/ava-labs/hypersdk/pull/1139/files#r1679210787