test vrf selection policy#5425
Conversation
Summary of ChangesHello, 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 introduces a diagnostic step to the VRF policy-driven TE test suite. By capturing and logging the device version information, it improves the observability of the test environment, aiding in troubleshooting and verification of the DUT state during test runs. 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 the 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 counterproductive. 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. Footnotes
|
|
/fptest virtual |
Pull Request Functional Test Report for #5425 / 3a07b14Virtual Devices
Hardware Devices
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a step to log the device version using a raw CLI command in the TestGribiDecap test. The review feedback correctly identifies that using vendor-specific CLI commands should be avoided for vendor neutrality and that the logic should be encapsulated within a t.Run subtest to comply with the repository's style guide. Alternatives like dut.Version() or OpenConfig queries were suggested.
| if res, err := dut.RawAPIs().CLI(t).RunCommand(ctx, "show ver"); err == nil { | ||
| t.Logf("Output of 'show ver':\n%s", res.Output()) | ||
| } else { | ||
| t.Logf("Failed to run 'show ver': %v", err) | ||
| } | ||
|
|
There was a problem hiding this comment.
The use of vendor-specific CLI commands like show ver should be avoided in feature profile tests to maintain vendor neutrality. Additionally, per the repository style guide, all test logic and logging should be encapsulated within t.Run subtests to ensure the test output clearly reflects the execution steps. If logging the device version is necessary, consider using the vendor-neutral dut.Version() method or querying the appropriate OpenConfig path.
References
- Use t.Run for subtests so output clearly reflects passed/failed steps. (link)
|
/fptest virtual |
2 participants
No description provided.