読者です 読者をやめる 読者になる 読者になる

テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(writeboost report) 思い付くテストは全部書くしかない

昨日気づいたのだが, ライトブーストのclone数が増えている. githubのプロジェクトをcloneすることはまぁまぁハードルがある. ソースコードをちょっと読むだけならばブラウザで見ればいい. ドキュメントを読むだけでもそう. cloneするということは,

  • 使ってみる
  • エディタでがっつりと読みたい

のいずれかだと思う.

人間の印象は第一印象で80%が決まると言われる. ソフトウェアも同じだ. 使ってみていきなりバグったらもう二度と使わない. 特にライトブーストは,

  • 企業がバックにないから, 質が低いと思われる
  • SSDキャッシュはbcacheなどの既存プロジェクトがあるから, どうしてもライトブーストというモチベは低い

という不利があるから, 一回信用を失ったら二度と取り返せない. SSDキャッシュを使いたいというストレージ管理者はアプリプログラマのように10万100万とうじゃうじゃいるわけではないから, そもそも母数としてチャンスも少ない.

そもそも, ストレージソフトウェアやOSなどの基盤ソフトウェアは, バグがあったらその時点でゴミだ. ライトブーストには数千時間をかけたと思うが, もしバグがあったらその時点で, 結果としてはやらなかったのと同じになる. もちろんキャリアとしては残るしOSS奨励賞などももらったから十分に回収はしてるけど, 結果として, 完全でないストレージソフトウェアはゴミ以外のなにものでもない. これがアプリとは違うところだ. アプリは, ちょっとバグったとしても被害はそこで閉じる. てへぺろで許される. しかし基盤ソフトウェアはそれを利用するすべてのアプリに損害を与えるし, 場合によってはビジネスを破壊する. だから, バグが1つでもある基盤ソフトウェアは使い物にならない.

ライトブーストは, 設計がクリーンという評価を受けているのだが, これは, 最初からバグ撲滅を狙っているからである. テスタビリティにも最初から気を配っており, キャッシュヒットの様子などを統計データとしてとれる. writeboost-test-suiteでは, これを使ってテストケースを書いている. また, タイミング問題なども出来るだけ排除し, テストプログラムからライトブーストの静止した状態を観測出来るようにしている.

writeboost-test-suiteは, テストを書くことを容易にする. このフレームワークを使うと, デバイスがエラーを起こした場合の挙動をemulate出来る(fault injection). ブロックデバイスは結構エラーを起こすし, エラーハンドリングは盲点になりやすいから必要な機能だ. device-mapper-test-suiteにはこれがなかったというのがwriteboost-test-suiteをスクラッチで書いた最大の理由といっても過言ではない.

というわけで, とにかくどんな時でもテストを思いついたらメモって, どんなくだらないものでも実装するようにしている. たぶん, ソースコード上のロジックのバグは100%取り除くことが出来る. しかし, ここが難しいところなのだが, カーネルソフトウェアには, ストレージほど抽象度の高いものであったとしてもマシン依存の問題が時々現れる. エンディアンなど自明なものに限らず, おそらくまだ存在すると思われるが, これは私の力だけではどうしようもない. 私がやることは,

  • バグが報告された時にマシン依存だと確信を持てるレベルにロジックのバグを取り除くこと
  • ライトブーストを多くの人に使ってもらい, バグ報告を受けること

だけど, とりあえずこのままテストを書いていってバグを探すことを続けるのが今は一番だと思っている. 本当に良いものならば自然と広まっていくのがインターネットの世界だから.

最新の2.2.3にはまぁまぁの自信がある. 試しているのは外国人ばかりなので, 日本人にも試してもらいたいと思っている.

github.com