-
Notifications
You must be signed in to change notification settings - Fork 38
test(js) refactor decoding tests #738
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
base: main
Are you sure you want to change the base?
Conversation
… compare the results
…into refactor-tests merge recent changes
…into refactor-tests
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #738 +/- ##
==========================================
+ Coverage 83.58% 87.93% +4.34%
==========================================
Files 53 54 +1
Lines 2345 2552 +207
Branches 537 572 +35
==========================================
+ Hits 1960 2244 +284
+ Misses 357 286 -71
+ Partials 28 22 -6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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 might be reading this wrong, but I see some encoding methods that are not "hard coded".
If this is the case, and there might be in the far future a javascript encoder, we might as well place these methods in files that are symmetrical to the decoding files (in terms of naming).
Later on, we could use them in the test like you did.
Let me know if this makes sense.
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 seems there's a lot of logic in this file, I'm not sure if it is related to the previous comment or not, but it's worth taking it into account.
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 mean i can place them in a encoder file structure, but the encodings I included for the tests are really only the most basic encodings and half of the logic in this file is needed for creating stream(metadata). If I were to set those up manually we would have at least 10000 of extra code. The only thing that is "hard coded" are the FSST Symbol Table Streams.
TLDR: half of decodingTestUtils.ts is only for test setup and encodings like ZigZag can be moved to a symmetrical encoder directory. But I am not sure if this makes sense 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.
Let's start with something, move as much code as possible to encoding folder/files.
If you can take a bit more time to create basic encoding methods that can facilitate for "full cycle encode-decode" tests that would be the best approach, but I don't know how complicated that is, I would assume that for the basic stuff this should be trivial.
This will both make the tests easier to read and maintain and help us in the future if we decide to create a js encoder.
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 will move them to encoding folders and add tests where coverage is still lacking.
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.
"full cycle encode-decode" tests are already happening
|
Please checkout the coverage of the decoding files:
I would expect those to only have missing coverage for some edge cases when throwing, or code that we don't have a good way to test (morton?). |
…ropertyDecoder.spec.ts
for more information, see https://pre-commit.ci
| * - Varints: numValues, byteLength | ||
| * - If RLE: Varints: runs, numRleValues | ||
| */ | ||
| export function encodeStreamMetadata(metadata: StreamMetadata | RleEncodedStreamMetadata): Uint8Array { |
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.
Shouldn't this be part of the encoding?
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 is really specific to the testdata streams so i would keep it here
| it("should decode NONE signed", () => { | ||
| const metadata = createStreamMetadata(LogicalLevelTechnique.NONE); | ||
| // ZigZag encoded: positive values are multiplied by 2 | ||
| const values = new Float64Array([4, 10, 6]); // zigzag encoded [2, 5, 3] |
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 it possible to create something like encodeFloat64Buffer([2,5,3]) to improve full-circle readability?
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 would expect this file to have similar folder structure to encoding, this way there's a way to see which method is the counter part of the decoding method.
I would expect to heve integerStremEncoder file, propertyEncoder file etc.
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 understand what you mean but that would require a whole encoder for all the different streams and at that point we would have half of a fully functioning MLT encoder. So basically it would take a lot more effort then just creating streams like I do in the test utils. But the tests would be verry easy to adapt to using a fully implemented encoder once there is one.
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 there might be a middle ground here, improve test readability by adding some encoders without implementing everything...
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.
Yes but I think the tests are testing the decoder well enough and full cycle testing could wait until we introduce a encoder. There are still other gaps like fastPfor decoding we are missing that should be fixed before we spend a lot of time on 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.
The tests here seems very low level decoding - int, double, float etc, I'm failing to see how this would be a big effort...
This PR refactors the decoder test suite to improve test quality by introducing shared test utilities and rewriting tests to use proper data encoding.
Before tests used raw byte streams or mocked metadata objects. Now tests properly encode data using encoding utilities.