MailNews:Automated Testing: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(→‎xpcshell tests: Add note about Mac tests leaking)
Line 12: Line 12:


This page and its sub-pages are intended to describe and provide pointers to the available test mechanisms within MailNews and supporting information for developers and testers.
This page and its sub-pages are intended to describe and provide pointers to the available test mechanisms within MailNews and supporting information for developers and testers.
Thunderbird brainstorm on unit test ideas are [[Thunderbird:Unit_Test_Ideas|also available]].


== Rules and Review Policy ==
== Rules and Review Policy ==

Revision as of 00:59, 17 June 2008

<< Back to MailNews:Home Page

Introduction

Automated testing for MailNews (i.e. Thunderbird and the Mail/Newsgroups part of SeaMonkey) is becoming more important. We need to ensure that when we are fixing bugs we do not introduce regressions in other areas of the code. Automated testing is a vital part of this.

Tests are not only useful for checking for regressions, but they can help developing and testing of patches. For example, xpcshell tests are very good at checking interfaces, and are very quick to run as they only require a "make check" - you don't have to start up the application, and all the tests happen automatically in a consistent manner.

See also MailNews:Performance Testing.

This page and its sub-pages are intended to describe and provide pointers to the available test mechanisms within MailNews and supporting information for developers and testers.

Thunderbird brainstorm on unit test ideas are also available.

Rules and Review Policy

These apply only to the mozilla/mailnews and mozilla/mail directories.

  • At the moment, tests are not required to be submitted with patches, or for patches to be accepted into the tree. Developers and contributors should consider adding tests within MailNews where possible.
    • Once the testing infrastructure has been expanded so that it is possible to write tests for most areas of the code, this may change.
  • All tests shall be reviewed by a module owner or peer.
    • Where tests are included in a code patch that fixes a bug, no further review is necessary.
    • Where tests are not included in a code patch, a review by the module owner or peer is required. No super-review is required.
  • When a test is committed to the tree, the appropriate bug shall have the in-testsuite+ flag set.
  • Certain build-config or tooling bugs which don't affect the actual product cannot be usefully tested. These bugs should have the in-testsuite- flag set.

See the Module Owners page for the current module owners and peers.

toolkit review policies.

Useful Documentation and notes

The devmo pages have some good descriptions on how to start writing automated tests.

Not all the automated tests will work at the moment, some of them require new support architectures, some of them require other issues fixing before they will pass/work correctly.

Automated Tests

Notes for running on Trunk Builds

These apply to trunk builds of SeaMonkey and Thunderbird. They may also apply to other applications.

xpcshell tests

Some of the non-mailnews tests may currently fail in various places due to the following reasons:

Test Debug-only? Bug Reference Notes
test_default_index_handler.js No bug 427831 Broken if CVS directory doesn't exist
test_bug299716.js Yes bug 431139  
test_bug378216.js
test_bug394300.js
test_download_manager.js
test_bug356370.js Yes bug 428078
test_bug394717.js Yes bug 431147
  • Thunderbird builds will also fail in various places in core, see the dependencies of bug 406227.
  • Mac tests will leak memory and complain about it on 1.9 branch (CVS) due to bug 435853