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
internal/testrunner/runners/pipeline: unmarshal test results using UseNumber #717
internal/testrunner/runners/pipeline: unmarshal test results using UseNumber #717
Changes from 5 commits
0760b65
81bb305
6c30ec7
9b93a10
86af80f
0c260d1
93299d2
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.
Wouldn't be enough to check if there is something else there with
dec.More()
?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.
No, this won't work. Some trailing bytes are acceptable, others are not; a JSON stream can have arbitrarily large quantities of whitespace outside literals and this extends to trailing and leading data.
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.
dec.More()
ignores whitespaces, are there other acceptable bytes? The code I propose passes the test cases added in this PR (after adapting the error strings).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.
Or something like this could be done to keep this error message:
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.
Nice. I didn't notice that. To retain the error parity we'll need something like the second option or what I have. I'm not convinced that the assertion to
io.ByteReader
is simpler of lighter though. We expect that in the happy case that remaining will be ~0, and in the unhappy case remaining will still be ~small (it must have fit in memory), but we cannot guarantee thatdec.Buffered()
will return anio.ByteReader
, so we may miss cases.If we are happy to lose error parity, then
dec.More()
would be fine.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.
What I would like to avoid is to do parsing here (the
if b > ' ' || (b != ' ' && b != '\t' && b != '\r' && b != '\n')
line), and rely on the decoder for this.Regarding the error message, I don't have a strong opinion, but at this level I think that it is ok if we don't show the found character.
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.
OK. This will complicate the test code. I will do it next week.
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.
No need to complicate test code, actually I think that we could simplify it, and only check that it returns an error when expected, without checking the error message.
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.
Is the
-g
necessary here? Shouldn't it be caught due to differences compared to theexpected.json
file?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.
+1, I think this if is not needed,
elastic-package test
should fail if there are regressions in unmarshalling logic. If it doesn't fail, this is a different bug to be addressed in a different PR.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.
No, it won't be caught. This was the reason for the additional code previously. The issue is that it is not possible for a machine to measure the accuracy of some thing that is more accurate than it, and this is what that would be asking it to do; if the the code is regressed, then it becomes a less accurate machine and so become inadequate to test that the test cases (which are more accurate) are satisfied. This is all theoretically sound, but can be practically confirmed by running the tests at 9b93a10 with this change
They will pass.
Aleternatively, this also demonstrates the situation https://play.golang.com/p/CMsFSSjcd0f.
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.
Hmm.. to be honest, I'd accept that risk than introduce a sneaky workaround. It sounds to me like an edge case.
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.
Should I remove the tests? They essentially don't do anything without this.
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.
Let me challenge this. In this case, we're talking about the Go stdlib's nature, which unfortunately has this behavior. It means that we need to a test to detect a possible regression. I'm wondering if the unit test which calls
jsonUnmarshalUsingNumber
, then marshals back to[]byte
using the rightjson.Marshaller
can detect this issue. WDYT?EDIT:
https://play.golang.com/p/8xH6zmearh4 (it's similar/same? to what you have covered with your tests).
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.
The question that has to be asked is what does that test? Depending where it's put that could adequately test for all regressions, but as the code stands you will end up mocking essentially all of
(*runner).run
in order to achieve that.There are many moving parts here, breaking some of them would be detected, but breaking others will not. The fact that breaking some of them will be is a good reason to keep the package here. I'm at the end of an extremely long day, so I don't have the cognitive capacity to sort out which are visible and which are not right 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.
Ok, I see, you make a good point with the comparison of floats.