MailNews:Automated Testing

<< 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.

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

• MailNews:xpcshell tests
  • These currently run on the SeaMonkey tinderboxes, and report as TUnit. Thunderbird hopes to pick running of these up soon (bug 422817).

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.