もずはっく日記(2007年2月)

テストケースを作る人が居ない
初回投稿日時: 2007年02月24日06時58分06秒
カテゴリ: Bugzilla-jp
SNS: Tweet (list)

ついでにbugzilla-jpの現状の問題として考えてるポイントを一つ。

私はパッチを書き出す前は報告されたバグのテストケースを作り込んだり、HTML/CSSを個人的にがしがしとコード書きまくってバグを報告したりしていた。(レイアウト/描画のバグ件数が774件で、うち203件が私の報告。意外と割合が高い。もちろんこれはよくない傾向だ。)

で、共に後継者が不在なのであまり問題は表には出ていなかったが、reflowリファクタリングでregressionが多いにも関わらずbugzilla-jpにはほとんどその報告が無いというのは問題だと思う。またあったとしてもそのテストケースを作って再現状況を絞り込む人も居ない。

再現状況を絞り込もうとすると、処理を知らなくても仕様を熟知して、コードの有る程度の設計を推測してバグが発生する条件としない条件の境目を考えなくてはいけない(それを推測できない場合は当たりが付けられない分、テストケースの作成が難しくなる)。また、出来る限り一目で理解可能なシンプルで有用なソースを書くコツがあるのだが、それを掴まなくてはいけない。だが、考えてみればこれって結構特殊な能力かもしれない。だって、そもそもそんな能力、bugzillaでしか役に立たない訳だから。

一応、参考のために作成のコツを列挙しておくと、

• 再現するために必要な要素、プロパティを徹底的に必要最小限まで絞り込む。無駄があればそれは原因推測の邪魔になる。
• ボックスモデルのバグの場合、borderを利用して分かりやすく作る。ボックス毎に色やスタイルを変える等。もちろん、インラインボックスのテストの場合テキストの色を変えるのも手。ただし、目が痛くなるようなきつい配色にはならないようにだけ注意。
• 複数示したい状態がある場合、可能な限りスクロールせずに比較できるようにコンパクトにまとめる。
• テストケースに関する説明を丁寧にする。理想はテストケース内に見出しで入れれること。もしくは、テストの内容によってはボックスのコンテンツとして。また、仕様上どうあるべきかをシンプルに説明する。説明が長い場合は素直にテストケースを添付する際にコメントとして付け加える。
• zip圧縮のようにブラウザから手軽に見ることのできない形式では添付しない。
• コメント欄にソースを貼り付けるというのも駄目。
• とことんシンプルなテストケースで済むならURL欄にdataスキームで書き込むのもアリ。

過去の私の添付したテストケースがこれに従っていないものも多いが、そこはそれ。そういった失敗から学んでのことである。進歩するから黒歴史があるということで。