シンプルなテストケースを作ろう

実際にコードを書けない人でも、開発に大きく貢献しようと思えば、テストケースを作り、bugzillaの該当のバグに提出する、という作業で貢献することができます。役に立つテストケースは実際に、パッチを作成するエンジニアにとって非常に大きな助けとなります(私も昔、パッチが書けなかった時はよくやっていました)。

実際にパッチを書いている立場から、どのようなテストケースが有用で、助かるのかと問われれば、シンプルで、かつ、分かりやすいという(時には相反する)二つの重要なポイントを守っておいてください、と答えます。

例えば、キー入力やマウスの操作である等、挙動に関するバグのテストケースである場合、余計なスタイルシート等は指定せず、必要最小限のもののみを指定するようにします。なぜなら、エンジニアは検証時に、様々なスタイルが適用されているテストケースを見ると、それら全てがバグに関係があるものなのかと考えてしまうかもしれませんし、また、少なくとも疑ってかかる必要が出てくるためです。さらに、本当に重要なポイントが分かりにくくなる、という点も見逃せません。

これらの事から、HTML自体の記述では、ブロックレベルの要素ならdiv要素、インラインレベルの要素が必要な場合はspan要素を使うのが好ましいことが理解してもらえると思います。他の要素はこれらの要素にスタイルを追加していたり、特殊な動作を追加したりしているため、それそのものが複雑だからです。

ですが、複数の要素を配置する必要があり、それらの違いが分かる必要がある場合、例えば、HTMLやCSS等のレイアウトやレンダリングに関わるバグのテストケースではボックスごとに異なる色のborderかbackground-colorのどちらかのみを指定する必要があることがあります。一般的に、レイアウトに関するバグの場合にborderの利用には注意が必要です。borderはその太さの分、レイアウトに影響を与えてしまうためです。ですが、background-colorを指定した場合はその背後にあるボックスが見えなくなるという、特性があるためz-indexのテスト等では使いにくい、または使えないことがありますので、ケース毎に判断していく必要があります。

また、エンジニアはテストで長時間そのテストケースを見ることが多々ありますので、あまり目に優しくない色の組み合わせや、ビビッドな色の利用には注意しましょう。

HTML自体を記述する場合にも、strictなHTMLにこだわる必要はないという点に気をつけてください。テストケースがアクセシブルである必要や、複数のブラウザで表示できる必要は全くありません。Gecko (or Firefox)のためのテストなので、これでテスト可能な最低限のシンプルなコードを書くのが最も良いのです。

例えば、Standardsモードでレンダリングさせたい場合、<!DOCTYPE html>と、HTML5のDOCTYPE宣言を入れるだけでかまいません。長い、HTML4のDOCTYPEを挿入したりする必要はありませんし、Standardsモード、Quirksモード、どちらでも良い場合であればこの一行そのものが必要ありません。

同様に、html要素、head要素、meta要素、body要素、さらにはtitle要素も必要ありません。文字コード宣言も必要ありません。UTF-8で作成し、bugzillaに添付すれば、bugzillaはデフォルトで、ヘッダにcharset=UTF-8を付与して送信します。UTF-8以外のテストケースが必要な場合であっても、meta要素で文字コード宣言を行わなくても、添付時にContent Typeの項目で、enter manuallyを選択し、text/html;charset=Shift_JISと指定するだけで済みます。

最後に、シンプルなテストケースを作ることに成功しても、シンプル過ぎるが故に他人には分かりにくすぎるテストケースになってしまっている可能性が高いことには注意してください。例えば、CSSのテストではテストケースがどのように表示されるべきなのか分かりにくいことがよくあります。このような場合は別のファイルに、よりシンプルなスタイル指定で、本来表示されるべきリファレンスを作ってしまうと良いでしょう。そうしておけば、開発者はそれらのファイルをそのままreftestに流用可能です。これは、開発者の負担を大きく下げてくれますし、長期間、バグが放置された後も、バグが再現しなくなっているのかどうかの検証が誰にでも簡単に確実に行えるようになります。

それ以外の場合には、テストケースを添付する際のコメントでしっかりと説明しておきましょう。

テストケースを書くというのは地味ですが難しい作業です。つまり、この作業をパッチを作成できる人がやるのはプロジェクト全体としては非常に効率が悪いと言えます。実際にパッチを作成することに比べれば明らかに(技術的にも時間的にも)敷居は低いのでより多くの方がこの分野で活躍されれば、プロジェクト全体の開発速度を上げることに貢献できます。我こそは、という方は是非参加してみてください。