Hola folks,
As a contributor, each of us is always striving hard in the ocean to open more and more pull-requests, but being a contributor just doesn't mean only raising PRs, it also means reviewing other PRs, pointing out mistakes, helping others in improving the code-quality/code-reusability/code-readability, helping in finding missing edge-cases that haven't been tackled yet, giving your opinions, writing LGTM, CITY helps nothing but just improving the confidence and engagement of the PR author.
So put on your Quality Tester hats because here I'll talk about how to test the PRs with the label component/mesheryctl i.e. pull-requests related to mesheryctl
Okay before we start, I'll like to tell you about GitHub CLI, it helps you checkout PRs very easily in your local system.
The very first step is to review the PR, suggest changes if you think of any, ask queries, help the author to improve the code quality/readability/reusability, ask questions because asking helps you learn asking more better questions next time.
PR authors either attach a video showcasing expected behavior or add written instructions about their fix under User Acceptance Behavior
Now it's the time to checkout PR in your local system, we can check out any PR like this
1gh pr checkout https://github.com/meshery/meshery/pull/4823You can check if you're into the same branch as the PR author with
1git branchWell, if we're testing a PR related to mesheryctl, we need to build the binary from the same branch. change your directory to
mesheryctlfolder and run1makeThis will create a mesheryctl binary according to your OS in the same directory
Now it's time to test out this newly built binary according to what's been tackled in the PR and related issues. For e.g.
system starthas some new functionality, make sure you followed the pull-request/linked-issue instruction for env setup, as sometimes fix/features are tackling an issue with a specific type of environment.
1./mesheryctl system start
the ./ helps us in using the newly built cli-binary present in the current directory which we built in 5th step
- make sure we have a similar experience as mentioned in the Video or the instructions added to the PR. but the wait is it okay to give green flags to the PR? not yet tbh. We as a tester should turn a little evil and think of the relevant situations/environments which might not have been tackled but should be(basically we're trying to break the new feature/fix)
- After spending a good amount of time testing the new behaviors, old standard behaviors, new test cases, few edge cases. We can provide new insights to the PR author about the behavior in your system, depending on our experience we can ask the PR author to address our new queries, or we can appreciate the work, or give green flags to the PR.
Wow, that was a ton of work there. well being a Tester is tough but very important before we merge pull requests. Every PR should be marked green with end-to-end testing before merging, we as a project are using GH Workflows to perform standard golang-testing but manual end-to-end testing completely removes margins of error.
