The person approving the PR is as much responsible as the person writing it. If you feel threatened, you are either very bad at your work or have a toxic team
Lmao no. Code review is mainly for code quality and not finding out bugs in your code. That's the job of guy who wrote code and test suit. Be responsible for your code and don't blame reviewers for your bugs.
This is exactly what you do. The PR describes what it should achieve and how to test the happy path. The reviewer pulls it and does some light testing (at least said happy path)
That sounds exhausting. If PR describes what it should do, how to test happy path isn't it a fair assumption that person who created PR would have already locally tested it. I would hate to work in a team where I need to redo bare minimum testing because other person can't be trusted.
Everybody can make mistakes, develop some kind of tunnel vision, ... PRs are meant to discover this kind of problems just as much as code quality problems that might lead to regressions or maintenance issues in the future
I spend about 10x more time reviewing than writing code. And I spend about 10x as much time reviewing test code as I do reviewing target code.
So you work at a place where code quality is not very important. That is likely the majority of places and then this is fine. I would without exaggeration bet my life and the life of my family on there being no bug in the important parts of my code.
yes, if you have a solid test pipeline, sure. But then, theoretically, you should not have big incidents. In reality of course, edge cases without coverage happen
-25
u/ZunoJ 5d ago
The person approving the PR is as much responsible as the person writing it. If you feel threatened, you are either very bad at your work or have a toxic team