blob: 7db11230ab32781723c0be4e353e3b6d3cac52d1 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
---
title: Mozilla Toolkit のためのユニットテスト
slug: orphaned/DevNews/20061106
tags:
- DevNews
- DevNews:General
original_slug: DevNews/20061106
---
<p>Gecko 1.9 / Firefox 3 企画会議で出た <a class="external" href="http://wiki.mozilla.org/Firefox3/Goals">最重要目標</a> の一つに、自動試験の実現と、われわれのコードでのテスト容易性の評価があります。将来の目標として、ツールキットモジュールへの全てのチェックインに対する新しいユニットテストのポリシーを立ち上げようとしています。</p>
<h4 id=".E3.83.86.E3.82.B9.E3.83.88.E3.82.92.E8.A1.8C.E3.81.86.E3.81.93.E3.81.A8.E3.81.AE.E9.87.8D.E8.A6.81.E6.80.A7" name=".E3.83.86.E3.82.B9.E3.83.88.E3.82.92.E8.A1.8C.E3.81.86.E3.81.93.E3.81.A8.E3.81.AE.E9.87.8D.E8.A6.81.E6.80.A7">テストを行うことの重要性</h4>
<p>ユニットテストはさまざまな効果をもたらします :</p>
<ul>
<li>テストによりコードの作成者とレビューアはパッチが正しく動作するとの確信がもてます</li>
<li>テストケースを書くことは、開発者にとって境界条件を発見するいい刺激になります</li>
<li>テストによりレグレッションを早く発見するよい手法が得られ、同じレグレッションを二度と発生させないようにすることができます</li>
<li>ユニットテストは API をどのように利用するかの実際に動作するサンプルを提供し、文書作成にもかなり有効です</li>
</ul>
<p>このように、統合されたユニットテストには、全ての個々の変更のコストとリスクを小さくする効果があります。これによりプロジェクトは <a class="external" href="http://weblogs.mozillazine.org/roadmap/archives/2006/10/mozilla_2.html">Mozilla 2</a> に向けた主要なアーキテクチャの向上を速くそして確かなものにできるでしょう。</p>
<h4 id=".E5.AE.8C.E5.85.A8.E3.81.AA.E7.AF.84.E5.9B.B2_.28Complete_Coverage.29" name=".E5.AE.8C.E5.85.A8.E3.81.AA.E7.AF.84.E5.9B.B2_.28Complete_Coverage.29">完全な範囲 (Complete Coverage)</h4>
<p>ユニットテストによって目標を達成するためには、新しいコードに対するユニットテストを作成する必要があります。そして、テストは定期的に実行され、結果を開発者向けに公表し修正されるようにしなければなりません。Mozilla においては、クライアントに関するコードの大半のテストをビルドシステムの make check の段階で実行しなければならないことを意味します。そして、その結果を TUnit のように tinderbox へ報告しなければなりません。</p>
<p>わたしは、全ての toolkit コードにおいて完全にユニットテストを実行したいと考えています。そのために、<a class="external" href="http://www.mozilla.org/projects/toolkit/review.html">チェックインポリシー</a>に次の項目を追加しようとしています。</p>
<ul>
<li>全てのパッチは make check の段階で走らせるための<a href="ja/Mozilla_automated_testing">ユニットテスト</a>を含まなければなりません。ユニットテストがコミットされれば、バグに <code>in-testsuite+</code> フラグを設定しなければなりません。</li>
<li>ユニットテストはパッチに含まれて居なければならず、ほかのコードと同様にレビューされるべきです。</li>
<li>make check の段階でテストを実行できない場合は、Dave Liebrech か Robert Sayre に相談しほかのテストシステムを利用できないかを検討します。</li>
<li>必要な<a href="ja/Mozilla_automated_testing">ユニットテストフレームワーク</a>が提供されていない場合、開発者は適当なテストコードを書いてコミットすべきです。そして、必要なフレームワークについてバグを立てるべきです。<code>in-testsuite?</code> フラグがそのフレームワークが導入され、テストコードが自動実行されるまで設定されているべきです。</li>
<li>特定のビルド設定かあるいは実際のプロダクトには影響しない tooling bug はきちんとテストされないでしょう。これらのバグは <code>in-testsuite-</code> フラグが設定されるべきです。</li>
</ul>
<p>また、toolkit の古いバグ全てについてボランティアに次のことをお願いします。<code>in-testsuite?</code> か <code>in-testsuite-</code> フラグをもつ <code>FIXED</code> とされたバグに優先順位をつけて、2007 年 3 月 1 日までに適切なテストケースを作成するのを助けてください。これは、意欲的な目標ですが、実現できると考えています。そして Mozilla 2 ブランチに必要とされる前に完全に行うことが重要です。</p>
<p>Robert Sayre はツールキットのユニットテスト管理者として活動することを容認してくれました。もしあなたが開発者で、ユニットテストをどう書くかについてや、どのユニットテストフレームワークが利用可能かについて質問があれば、最初に<a href="ja/Mozilla_automated_testing">ドキュメントを読んで</a>からコンタクトを取ってください (IRC では sayrer です)。彼にユニットテストを書いてくれ、とは頼まないでください ;-) 。Dave Liebrech (IRC では davel です) もユニットテストフレームワークのデザインと実装について質問に答え、助けになってくれるでしょう。</p>
<h4 id="Review_.E3.81.A8_Testing_.E3.81.AF.E7.9B.B8.E8.A3.9C.E9.96.A2.E4.BF.82" name="Review_.E3.81.A8_Testing_.E3.81.AF.E7.9B.B8.E8.A3.9C.E9.96.A2.E4.BF.82">Review と Testing は相補関係</h4>
<p>ユニットテストがレビューの代用品となるわけではないことを明記しておくのは重要でしょう。テストはコードが思ったとおりに動作することを確認するために重要です。レビューは、コードが文書になっており、人間が理解できる形であり、ほかのコードと動くように設計されていることを保障するために重要です。Mozilla では昔からレビュー要求についてはうまく動いており、ユニットテストについても同じような環境を構築したいと考えています。ユニットテストとレビューは相補性にある活動で、われわれのコードを改善し続けるには両方とも必要なものです。</p>
<p>注 : このポリシーに関しての質問や議論は、mozilla.dev.platform ニュースグループ (<a class="link-news" href="news://news.mozilla.org/mozilla.dev.platform">NNTP</a> か <a class="external" href="http://groups.google.com/group/mozilla.dev.platform">google groups</a> 経由など) にお願いします。</p>
|
