A “test change” could be a new test, an expansion of an existing test, a test bug fix, or a modification to existing tests to make them match new spec changes.
CTS contributors should contribute to the tracker and strive to keep it up to date, especially relating to their own changes.
Filing new draft issues in the CTS project tracker is very lightweight. Anyone with access should do this eagerly, to ensure no testing ideas are forgotten. (And if you don’t have access, just file a regular issue.)
Enter a draft issue, with the Status set to “New (not in repo)”, and any available info included in the issue description (notes/plans to ensure full test coverage of the change). The source of this may be:
Note: at some point, someone may make a PR to flush “New (not in repo)” issues into TODO
s in
CTS file/test description text, changing their “Status” to “Open”.
These may be done in bulk without linking back to the issue.
As necessary:
Convert the draft issue to a full, numbered issue for linking from later PRs.
Open one or more PRs, each linking to the associated issue. Each PR may is reviewed and landed, and may leave further TODOs for parts it doesn’t complete.
.unimplemented()
so a reviewer can evaluate the plan before you implement tests.)When no TODOs remain for an issue, close it and change its status to “Complete”. (Enter a new more, specific draft issue into the tracker if you need to track related TODOs.)