More about testing

[Imported from Trac: page PatchReviewProcess, version 23]
daira 2013-08-08 12:55:25 +00:00
parent 90b7824499
commit b48f811642

@ -42,6 +42,6 @@ A few simple suggestions:
## Using trac and github
The patch you're reviewing might be given either as an attachment, or as a github pull request. If it's the latter, then it's encouraged to use line comments on github for detailed comments or questions on the code. However, you should also write a short summary of the review on the trac ticket. (Sometimes this can be as simple as "+1" if there are no issues to discuss.)
The patch you're reviewing might be given either as an attachment, or as a github pull request. If it's the latter, then it's encouraged to use line comments on github for detailed comments or questions on the code. However, you should also write a short summary of the review on the trac ticket. (Sometimes this can be as simple as "+1" if there are no further issues to discuss.)
In all cases it's recommended to apply the patch or check out the code and run the full test suite locally (using `python setup.py test` since a rebuild is usually necessary), to check that it passes. All committed code should also be free of pyflakes errors or warnings.
In all cases it's recommended to apply the patch or check out the code and run the full test suite locally (using `python setup.py test` since a rebuild is usually necessary), to check that it passes. You'd be surprised how often a patch author thinks it passes tests, but a "harmless" last-minute change, portability problem, or nondeterministic race condition causes it to fail when checked. (There's usually noneed to test on multiple platforms at this stage though -- that's whatthe buildbots are for.) All committed code should also be free of pyflakes errors or warnings.