| ... | @@ -49,4 +49,4 @@ When an issue is reported, it may contain more or less accurate description of t |
... | @@ -49,4 +49,4 @@ When an issue is reported, it may contain more or less accurate description of t |
|
|
|
|
|
|
|
Once we have a reduced testcase, it is generally possible to convert it into one or more unit tests. When it is the case, we mark the issue as **Unit Test Wanted**. The conversion may be more or less straightforward, depending on the kind of testcase we have. For example, an issue which involves a complex scenario to be reproduced may require a few lines of code to simulate each user action. At the opposite, issues related to layout or LaTeX conversion can generally be written using the reftest paradigm i.e. using only a reference and test page.
|
|
Once we have a reduced testcase, it is generally possible to convert it into one or more unit tests. When it is the case, we mark the issue as **Unit Test Wanted**. The conversion may be more or less straightforward, depending on the kind of testcase we have. For example, an issue which involves a complex scenario to be reproduced may require a few lines of code to simulate each user action. At the opposite, issues related to layout or LaTeX conversion can generally be written using the reftest paradigm i.e. using only a reference and test page.
|
|
|
|
|
|
|
|
Finally, when tests are written and included in the testsuite, we mark the issue as **In Testsuite**. In theory, this means that we have unit tests covering all aspects of the bug and hence the issue remains in the In Testsuite status forever. |
|
Finally, when tests are written and included in the testsuite, we mark the issue as **In Testsuite**. In theory, this means that we have unit tests covering all aspects of the bug and hence the issue remains in the In Testsuite status forever. If we can not write a unit test for a given issue we use the tag **Do Not Write Automated Test**. |
