In environments where pairing is rare and code reviews are the favoured means of getting a second pair of eyes across some code, I've typically made a point of at least running the code I'm reviewing.
Usually in the course of running the code, I'll experiment with a few dodgy cases just to make sure everything behaves as expected. Extra points if I merge the PR branch locally to be truly sure it plays nicely with the master branch.
It can (quite commonly) be difficult to infer the full scope of a piece of code's behaviour just by reading it (and its test cases). I'm a huge advocate for self-documenting code, but if that code was written by one person and I'm only the second set of eyes to examine it, its pretty likely that something dodgy has slipped past the author.
Additionally, by interacting with it in my own idiosyncratic ways, I may surface a use case that the author (of the requirement and/or the code) hadn't considered.
Ultimately, I don't see the harm in putting on our QA hat while we inspect our colleagues code. All it's doing is shortening the cycle time between bug creation and discovery, which is better for everyone.
What I'm not suggesting is every developer running through a full, manual, regression for every PR they receive. That'd result in diminishing returns very swiftly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In environments where pairing is rare and code reviews are the favoured means of getting a second pair of eyes across some code, I've typically made a point of at least running the code I'm reviewing.
Usually in the course of running the code, I'll experiment with a few dodgy cases just to make sure everything behaves as expected. Extra points if I merge the PR branch locally to be truly sure it plays nicely with the master branch.
It can (quite commonly) be difficult to infer the full scope of a piece of code's behaviour just by reading it (and its test cases). I'm a huge advocate for self-documenting code, but if that code was written by one person and I'm only the second set of eyes to examine it, its pretty likely that something dodgy has slipped past the author.
Additionally, by interacting with it in my own idiosyncratic ways, I may surface a use case that the author (of the requirement and/or the code) hadn't considered.
Ultimately, I don't see the harm in putting on our QA hat while we inspect our colleagues code. All it's doing is shortening the cycle time between bug creation and discovery, which is better for everyone.
What I'm not suggesting is every developer running through a full, manual, regression for every PR they receive. That'd result in diminishing returns very swiftly.