user101040: I'm not sure is there a right place to ask this question or not, if it is off-topic please let me know.
When reviewing a pull request of the Bitcoin Core, is it common to comment and inform others that all tests for this PR are passed? Or we should left comment only to inform failing tests?

user47827: As part of ACKing a top commit hash (post Concept ACK, Approach ACK) you are encouraged to explain what you did during your review that resulted in your ACK. As part of this comment it is perfectly fine (encouraged even) to say what tests you ran (and that they passed) on what operating system.
An example of such a review comment is this from Jon Atack's doc on how to review pull requests in Bitcoin Core:

ACK fa2f991, I built, ran tests, tested manually by doing X/Y/Z and reviewed the code and it looks OK, I agree it can be merged.

Some of the long term contributors may not do this and simply ACK the commit hash but maintainers have a better idea of what long term contributors are ACKing than a newer, less experienced contributor.

user208: If all you did was run the automatic tests on a standard system, and found they succeeded, there is little point in commenting at all.
The continuous integration system already runs all tests (in a variety of platforms), and pull requests are generally not merged before all tests pass. If all you did is run the tests on a fairly standard system, commenting that those tests pass doesn't add any information.
Of course, if you did more, for example:

You're using an unusual operating system, and the PR interacts with the OS in some way, commenting that the PR indeed doesn't break things for you is useful.
You did manual testing, by going through a scenario of operations (like RPC calls, ...) that aren't already covered by one of the PR's automatic tests, or you're testing on mainnet, or testing steps in the GUI (which aren't subject to automatic testing), that is useful too.
As you already pointed out in your answer, if a tests fails which normally doesn't fail for you before that PR, that is obviously useful as well.
If you did code review and are reporting the result of that (see Michael Folkson's answer), it won't hurt to add you also ran the tests.


101040: <p>I'm not sure is there a right place to ask this question or not, if it is off-topic please let me know.</p>
<p>When reviewing a pull request of the Bitcoin Core, is it common to comment and inform others that <strong>all</strong> tests for this PR are passed? Or we should left comment only to inform failing tests?</p>
 47827: <p>As part of <a href="https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#code-review" rel="nofollow noreferrer">ACKing a top commit hash</a> (post Concept ACK, Approach ACK) you are encouraged to explain what you did during your review that resulted in your ACK. As part of this comment it is perfectly fine (encouraged even) to say what tests you ran (and that they passed) on what operating system.</p>
<p>An example of such a review comment is this from Jon Atack's <a href="https://jonatack.github.io/articles/how-to-review-pull-requests-in-bitcoin-core" rel="nofollow noreferrer">doc</a> on how to review pull requests in Bitcoin Core:</p>
<blockquote>
<p>ACK fa2f991, I built, ran tests, tested manually by doing X/Y/Z and reviewed the code and it looks OK, I agree it can be merged.</p>
</blockquote>
<p>Some of the long term contributors may not do this and simply ACK the commit hash but maintainers have a better idea of what long term contributors are ACKing than a newer, less experienced contributor.</p>
 208: <p>If <em>all</em> you did was run the automatic tests on a standard system, and found they succeeded, there is little point in commenting at all.</p>
<p>The continuous integration system already runs all tests (in a variety of platforms), and pull requests are generally not merged before all tests pass. If all you did is run the tests on a fairly standard system, commenting that those tests pass doesn't add any information.</p>
<p>Of course, if you did more, for example:</p>
<ul>
<li>You're using an unusual operating system, and the PR interacts with the OS in some way, commenting that the PR indeed doesn't break things for you is useful.</li>
<li>You did manual testing, by going through a scenario of operations (like RPC calls, ...) that aren't already covered by one of the PR's automatic tests, or you're testing on mainnet, or testing steps in the GUI (which aren't subject to automatic testing), that is useful too.</li>
<li>As you already pointed out in your answer, if a tests fails which normally doesn't fail for you before that PR, that is obviously useful as well.</li>
<li>If you did code review and are reporting the result of that (see Michael Folkson's answer), it won't hurt to add you also ran the tests.</li>
</ul>
