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
Add integration tests with skip lists for failing tests #33
Add integration tests with skip lists for failing tests #33
Changes from 1 commit
10543fd
b80c6f9
db465ed
d8e8816
435dba9
ae74409
534d221
40ed246
71c5d5a
f9bff48
b1e2c09
70845d0
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.
This looks good. 👍
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.
These function comments refer to the old return types.
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.
Golang allows you to use the
string
data type to mean "arbitrary bytes", but I don't think we should use it that way. When I first read this function I was surprised because I thought ifdata
was astring
, it must already be text Ion so there'd be no need to encode it as text Ion. Only when I went and looked at the callsite did I realize that we were taking a binary buffer and callingString()
on it to get astring
instance.We should make sure we're only using
string
to refer to text throughout the APIs. If this is a quick change, you can include it in the PR. Otherwise, please open an issue so we don't forget to address it.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.
Fixed it in this test, create #48 to check throughout the project.
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.
Only caught this through linting, I'm getting a few warnings with unhandled exceptions.
Been looking through best practices for error handling in tests and it seems we can just make this obvious if we're ignoring an error by doing
_ = txtWriter.Finish()
.Looking into what the best practices are, but I'd feel failing early when an error occurred would be good. Let says if the text writer failed to finish, would this be obvious if we continued to ignoring the error and let the test fail later on? But, this could be a unit test vs integration test scenario, so maybe explicity ignoring the error for these cases is good enough.
Thoughts?
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.
Correct, I did not put error handling for
writer.Finish()
,stepIn()
andstepOut()
.My approach was to test the testfiles against different scenarios of this file (roundtrip, equivalency, loadBad). And if it fails at any point, the test fails. But open to suggestions.
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.
My general preference would be to explicitly check for errors from the writer and
t.Fatal(err)
; if something goes wrong during writing, that'll give you more information about the problem than one of the outputs being truncated.The writers should remember any errors they encounter along the way, no-op future writes, and return the error from
Finish
, so in theory you can get away with just checking the return value there. (Although that's maybe something that's worth testing more explicitly than it is tested now. :))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.
Done.
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.
It looks like
buf2
could be namedbuf
?