#PRreview #CodeReview #TeamCollaboration
Do you ever find yourself wondering if you should be testing the functionality of code when reviewing other team members’ PRs? 🤔 It’s a common question that comes up in many development teams. Here’s a few things to consider:
– In many cases, there is already a dedicated QA team in place to handle testing
– However, some teams expect all team members to test the functionality of code changes before approving a PR
– It ultimately depends on the team’s workflow and expectations
One possible solution could be to establish clear guidelines and expectations within your team. This way, everyone is on the same page and knows what is expected of them during the PR review process. How does your team handle this situation? Share your thoughts below! 💬
If you’re not one of the post-acquisition clowns I work with now that spend more time yapping about process than coding, then yes.
For real unless it is something trivial like changing a border color you really should
No QA person/team, and the answer is still almost never.
I trust our unit test, integration tests, multiple stages, staging time, slow roll outs, automatic roll backs, etc to do their jobs.
The only time I do run locally is if I read the code, and suspect a specific edge case may exists, but want to confirm before leaving a comment. In these cases though it usually isn’t because I don’t trust the tests, just that:
1. I don’t want the pipelines to be blocked unnecessarily
2. It is an away-teamer or similar, so it is better to personally check rather than just commenting for them to check.
Outside of the most critical systems running everything you review locally seems like overkill.
If your job is to be hated by everyone, yes
No.
You are bored and too much on your hands. lol
Sometimes, it depends.
Not usually though. Maybe 2% of the time.
Unless specified no.
No, I don’t waste time on that. If I suspect that something is off, I will either message the author or put the comment asking if they tested with what I suspect is going to break the code.
QAs are there to test the code, and they test based on their knowledge and based on what devs tell them.
We don’t have automated testing, so any time someone asks you to review you have to think up what tests to run on the spot and run them yourself.
My current place makes us and our builds can take 30-40 mins when switching branches to test.
Not always. I usually do it if I don’t understand the full code path, I’ll run a test in debug and follow through so I can see what’s happening outside of just the parts that were changed.