Gecko 1.9 / Firefox 3 企画会議で出た 最重要目標 の一つに、自動試験の実現と、われわれのコードでのテスト容易性の評価があります。将来の目標として、ツールキットモジュールへの全てのチェックインに対する新しいユニットテストのポリシーを立ち上げようとしています。
ユニットテストはさまざまな効果をもたらします :
このように、統合されたユニットテストには、全ての個々の変更のコストとリスクを小さくする効果があります。これによりプロジェクトは Mozilla 2 に向けた主要なアーキテクチャの向上を速くそして確かなものにできるでしょう。
ユニットテストによって目標を達成するためには、新しいコードに対するユニットテストを作成する必要があります。そして、テストは定期的に実行され、結果を開発者向けに公表し修正されるようにしなければなりません。Mozilla においては、クライアントに関するコードの大半のテストをビルドシステムの make check の段階で実行しなければならないことを意味します。そして、その結果を TUnit のように tinderbox へ報告しなければなりません。
わたしは、全ての toolkit コードにおいて完全にユニットテストを実行したいと考えています。そのために、チェックインポリシーに次の項目を追加しようとしています。
in-testsuite+ フラグを設定しなければなりません。in-testsuite? フラグがそのフレームワークが導入され、テストコードが自動実行されるまで設定されているべきです。in-testsuite- フラグが設定されるべきです。また、toolkit の古いバグ全てについてボランティアに次のことをお願いします。in-testsuite? か in-testsuite- フラグをもつ FIXED とされたバグに優先順位をつけて、2007 年 3 月 1 日までに適切なテストケースを作成するのを助けてください。これは、意欲的な目標ですが、実現できると考えています。そして Mozilla 2 ブランチに必要とされる前に完全に行うことが重要です。
Robert Sayre はツールキットのユニットテスト管理者として活動することを容認してくれました。もしあなたが開発者で、ユニットテストをどう書くかについてや、どのユニットテストフレームワークが利用可能かについて質問があれば、最初にドキュメントを読んでからコンタクトを取ってください (IRC では sayrer です)。彼にユニットテストを書いてくれ、とは頼まないでください ;-) 。Dave Liebrech (IRC では davel です) もユニットテストフレームワークのデザインと実装について質問に答え、助けになってくれるでしょう。
ユニットテストがレビューの代用品となるわけではないことを明記しておくのは重要でしょう。テストはコードが思ったとおりに動作することを確認するために重要です。レビューは、コードが文書になっており、人間が理解できる形であり、ほかのコードと動くように設計されていることを保障するために重要です。Mozilla では昔からレビュー要求についてはうまく動いており、ユニットテストについても同じような環境を構築したいと考えています。ユニットテストとレビューは相補性にある活動で、われわれのコードを改善し続けるには両方とも必要なものです。
注 : このポリシーに関しての質問や議論は、mozilla.dev.platform ニュースグループ (NNTP か google groups 経由など) にお願いします。