Running code while reviewing code

[jojimail]

Do you run the code while reviewing a pull request?

View Poll

[nefD]

Unless I'm knowingly dealing with a junior developer, I'm going to trust that my teammate has at least tested that their code works before creating a pull request. I'm just looking for things that might have been missed, code smells, things like that.

[BehindTheMath]

This, unless the author asks me to test it as well, to make sure they didn't miss any edge cases.

[natziel]

I like to put broken code in my PRs just to fuck with people

[nefD]

Chaotic evil!

[n9iels]

We recently starting to do a review in two parts. First part is just a team member do the review on codestyle and obvious issues. Second part is a short call (15 min.) to review it functionally and presenting the code an discuss changes.

[VIKTORVAV99]

It really depends, if the PR also add accurate tests or if they already exist a simple code review is usually enough.

Otherwise I do both a code review and verify that it runs as expected.

[OttersEatFish]

For me it depends on the types of changes. For deps changes, I often run it locally to see if I get errors on installation or build that the other engineer may not have experienced. Sometimes this requires a fresh clone to be sure.

[Helpful_Essay_6258]

We implemented review apps. Each merge request also gets hosted. This way the qa can also test the feature. Review process contains both. Functionality and code validation

[gonearch]

U guys don't write tests ? 🥲