Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • M MathJax
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 304
    • Issues 304
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 15
    • Merge requests 15
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • MathJax
  • MathJax
  • Wiki
  • Development process

Development process · Changes

Page history
Updated Development process (markdown) authored Apr 21, 2012 by fred-wang's avatar fred-wang
Show whitespace changes
Inline Side-by-side
Development-process.md
View page @ ff5eba86
......@@ -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.
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**.
Clone repository
  • Contributing
  • Development
    • Development Process
      • Release Process Checklist
      • Hotfix Release Process
      • Documentation Update Process
      • Source Control Policies
    • Design Documents
      • MathJax Roadmap
      • CDN Hosting
        • Directory Structure
        • CDN .htaccess settings
        • Managing Amazon Cloudfront distribution
        • Initial CDN investigation
      • Performance Discussion
      • Profiling and Diagnostics Tools
      • Configuration Options
      • Documentation generation guide
      • Testing