Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Mozilla Toolkit のためのユニットテスト

原文 原文 (archive.olg)
公開日時 2006/11/06
著者 bsmedberg
カテゴリ 一般

Gecko 1.9 / Firefox 3 企画会議で出た 最重要目標 の一つに、自動試験の実現と、われわれのコードでのテスト容易性の評価があります。将来の目標として、ツールキットモジュールへの全てのチェックインに対する新しいユニットテストのポリシーを立ち上げようとしています。

テストを行うことの重要性

ユニットテストはさまざまな効果をもたらします :

  • テストによりコードの作成者とレビューアはパッチが正しく動作するとの確信がもてます
  • テストケースを書くことは、開発者にとって境界条件を発見するいい刺激になります
  • テストによりレグレッションを早く発見するよい手法が得られ、同じレグレッションを二度と発生させないようにすることができます
  • ユニットテストは API をどのように利用するかの実際に動作するサンプルを提供し、文書作成にもかなり有効です

このように、統合されたユニットテストには、全ての個々の変更のコストとリスクを小さくする効果があります。これによりプロジェクトは Mozilla 2【訳注: 池田氏による和訳 に向けた主要なアーキテクチャの向上を速くそして確かなものにできるでしょう。

完全な範囲 (Complete Coverage)

ユニットテストによって目標を達成するためには、新しいコードに対するユニットテストを作成する必要があります。そして、テストは定期的に実行され、結果を開発者向けに公表し修正されるようにしなければなりません。Mozilla においては、クライアントに関するコードの大半のテストをビルドシステムの make check の段階で実行しなければならないことを意味します。そして、その結果を TUnit のように tinderbox へ報告しなければなりません。

わたしは、全ての toolkit コードにおいて完全にユニットテストを実行したいと考えています。そのために、チェックインポリシーに次の項目を追加しようとしています。

  • 全てのパッチは make check の段階で走らせるためのユニットテストを含まなければなりません。ユニットテストがコミットされれば、バグに in-testsuite+ フラグを設定しなければなりません。
  • ユニットテストはパッチに含まれて居なければならず、ほかのコードと同様にレビューされるべきです。
  • make check の段階でテストを実行できない場合は、Dave Liebrech か Robert Sayre に相談しほかのテストシステムを利用できないかを検討します。
  • 必要なユニットテストフレームワークが提供されていない場合、開発者は適当なテストコードを書いてコミットすべきです。そして、必要なフレームワークについてバグを立てるべきです。in-testsuite? フラグがそのフレームワークが導入され、テストコードが自動実行されるまで設定されているべきです。
  • 特定のビルド設定かあるいは実際のプロダクトには影響しない tooling bug はきちんとテストされないでしょう。これらのバグは in-testsuite- フラグが設定されるべきです。

また、toolkit の古いバグ全てについてボランティアに次のことをお願いします。in-testsuite?in-testsuite- フラグをもつ FIXED とされたバグに優先順位をつけて、2007 年 3 月 1 日までに適切なテストケースを作成するのを助けてください。これは、意欲的な目標ですが、実現できると考えています。そして Mozilla 2 ブランチに必要とされる前に完全に行うことが重要です。

Robert Sayre はツールキットのユニットテスト管理者として活動することを容認してくれました。もしあなたが開発者で、ユニットテストをどう書くかについてや、どのユニットテストフレームワークが利用可能かについて質問があれば、最初にドキュメントを読んでからコンタクトを取ってください (IRC では sayrer です)。彼にユニットテストを書いてくれ、とは頼まないでください ;-) 。Dave Liebrech (IRC では davel です) もユニットテストフレームワークのデザインと実装について質問に答え、助けになってくれるでしょう。

Review と Testing は相補関係

ユニットテストがレビューの代用品となるわけではないことを明記しておくのは重要でしょう。テストはコードが思ったとおりに動作することを確認するために重要です。レビューは、コードが文書になっており、人間が理解できる形であり、ほかのコードと動くように設計されていることを保障するために重要です。Mozilla では昔からレビュー要求についてはうまく動いており、ユニットテストについても同じような環境を構築したいと考えています。ユニットテストとレビューは相補性にある活動で、われわれのコードを改善し続けるには両方とも必要なものです。

注 : このポリシーに関しての質問や議論は、mozilla.dev.platform ニュースグループ (NNTPgoogle groups 経由など) にお願いします。

{{string.trim(($0 || '')) !== '' ? web.html('« ' + mediawiki.internal('DevNews:' + $0 + '|' + $0, "ja") + '') : ''}} {{string.trim(($1 || '')) !== '' ? web.html('' + mediawiki.internal('DevNews:' + $1 + '|' + $1, "ja") + ' »') : ''}}

Comment here to ensure newlines get recognized

ドキュメントのタグと貢献者

 このページの貢献者: Taken, Shimono
 最終更新者: Taken,