-
Notifications
You must be signed in to change notification settings - Fork 13
WIP test: unified converter tests #1085
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
And a cheeky fix to ensure we don't panic if we recieve malformed data with a shorter than expected dependency path.
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Summary of ChangesHello @rrama, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request focuses on enhancing the robustness and test coverage of the unified converter logic. It introduces a new, extensive suite of AI-generated unit tests that validate the converter's functionality for building upgrade paths, generating remediation advice, and handling various dependency-related scenarios. Additionally, a critical defensive fix has been implemented to prevent application panics when encountering malformed dependency path data, ensuring more graceful error handling. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
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.
Code Review
The pull request introduces a crucial fix in unified_converter.go to prevent panics when handling malformed dependency paths, significantly improving the robustness of the converter. Additionally, a comprehensive suite of unit tests has been added in unified_converter_test.go, which is excellent for validating the conversion logic and covering various edge cases. However, the new tests also highlight some existing "FIXME"s and logical "quirks" within the production code, particularly concerning the extractDependencyPath function's behavior and the IsUpgradable flag. Addressing these identified areas in future work would further enhance the accuracy and reliability of the unified converter.
| } | ||
|
|
||
| if len(dependencyPath) == 0 { | ||
| if len(dependencyPath) < 2 { |
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 change from len(dependencyPath) == 0 to len(dependencyPath) < 2 is a critical improvement. Accessing dependencyPath[1] when the slice has fewer than two elements would lead to a runtime panic. This fix correctly handles cases where the dependency path is empty or contains only a single element, preventing potential crashes.
| name: "Wrong behavior: multiple dependency paths - returns first one only (FIXME in prod code)", | ||
| // TODO: Delete this test and enable the test above when the fix has been implemented in the prod code. | ||
| finding: createFindingWithMultipleDependencyPaths(t, "[email protected]", []string{"[email protected]"}, []string{"[email protected]"}), | ||
| expected: []string{"[email protected]", "[email protected]"}, |
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 test case correctly identifies a "Wrong behavior" in the extractDependencyPath function, which currently only returns the first dependency path found, rather than all of them. The FIXME comment in the production code (unified_converter.go, line 333) also points to this. This limitation means that if a vulnerability is introduced through multiple dependency paths, the system might not fully represent all relevant information. It's important to address this in the extractDependencyPath function to ensure comprehensive vulnerability reporting.
| // Note: IsUpgradable is based on len(upgradePath) > 0, so [false] makes it true | ||
| // This is a quirk of the current implementation - might want to change to len(upgradePath) > 1 | ||
| assert.True(t, additionalData.IsUpgradable, "Current behavior: marked as upgradable when upgradePath=[false]") |
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 comment highlights a logical inconsistency where IsUpgradable is determined by len(upgradePath) > 0. If upgradePath contains only [false], it implies no actual upgrade is available, yet len(upgradePath) would be 1, making IsUpgradable true. This could lead to misleading information being presented to the user. Consider adjusting the logic to len(upgradePath) > 1 to accurately reflect when a true upgrade path exists.
Description
AI took the tests from #1042 and updated them to work with #1054 which went into main. It took 2 days of the AI spinning in the background, so hopefully it's good. It seems like it made up A LOT of new tests on top of Knut's tests. I haven't actually read what it has added yet, I will leave that to you to decide what you want.
Plus a cheeky fix to ensure we don't panic if we receive malformed data with a shorter than expected dependency path.
Checklist
make generate)make lint-fix)