Confirmed users
978
edits
User:Hsinyi/Gecko engineering: Difference between revisions
Jump to navigation
Jump to search
→Creating a patch & testing: tests
(→Patch scope & size: adding link) |
(→Creating a patch & testing: tests) |
||
| Line 103: | Line 103: | ||
Ensure to always stick with *the* real problem you want to fix. Be conscious about '''not''' adding unrelated fixes into that patch, even if they are super tiny. | Ensure to always stick with *the* real problem you want to fix. Be conscious about '''not''' adding unrelated fixes into that patch, even if they are super tiny. | ||
=====Tests===== | |||
*'''ALWAYS''' pursue this target - land code changes along with automated tests. There are exceptions or cases where testing isn’t possible using current testing frameworks. However, always ensure that you’ve thought about automated tests and you have a strong reason why no automated tests are needed or why landing without automated tests is acceptable. | |||
**There are cases when testing isn't possible using current testing frameworks: some parts of DnD, clipboard, printing etc. | |||
**Improving performance can often rely on existing performance tests. Or the patch might improve some very micro level issue, so adding a performance test for that might not be worth. | |||
**Scheduling changes should get tested by overall "do tests still pass" and performance tests (but we do need better tests for responsiveness etc.) | |||
**Scheduling changes for things like CC and GC are tested basically by looking at telemetry data. | |||
*'''Web platform tests (WPT)''' have helped a lot for us and for cross-browser behaviors. WPT should always be the default testing framework, where possible. | |||
*'''Write comments'''! Comments in the tests are particularly useful. It forces the patch author to think which all cases are tested and reviewers can also easily see that. | |||
*Always, ensure that a patch is '''well-tested''' and '''self-reviewed''' before it’s submitted for review. | |||
== Release health and product quality == | == Release health and product quality == | ||
== Roadmap and status communication == | == Roadmap and status communication == | ||