テストステ論

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

(writeboost report) writeboost-test-suiteとリネームしました

ソフトウェアの名前は重要です.

バイスマッパー一般どころか, ファイルシステムのテストに使ってもいいと思うので, 機能的なことをいえば「ストレージテストフレームワーク」というニュアンスを含みたいのですが, これは大風呂敷すぎ.

そこで, dmtestという名前で「デバイスマッパーのテストフレームワーク」ということにしていたのですが,

  • 目下, 最大のユーザはdm-writeboostである.
  • 完成したらdm-develでシェアするつもりだが, Joeがdevice-mapper-test-suite (or dmts)を捨ててこちらに移行してくれる確率は極めて低い. おれの「dmtsがダメだから新しいフレームワークScalaで再設計すべきだ」という意見自体にはプログラマ目線からは納得もしてくれると思いますが, 1) dmtsは彼(あるいはRH)がコントロール出来ている 2) 自分で設計したものだからおれよりは理解が深い 3) すでに書いてしまったテストが膨大なので移行の工数を払えない 4) あまりDMにモチベーションがない などの理由で, 移行まで行く確率は0.1%もない.
  • おれ自身, dm-writeboost (kernel module), dm-writeboost-toolsを持ってることもあり, writeboostという文字列を含むことの相乗効果がある.

などの理由で, writeboost-test-suiteということにしました. こうすると, dm-writeboostのことをどこかで知った人がおれのリポジトリを見て, 連鎖的にwriteboost-test-suiteを発見する確率は高くなります. このソフトウェアの最大の目標は, RHで公式に使われることですが, それが失敗しても「writeboostに対して自分でしっかりとしたテストスイートを書いている. しかもScalaで」ということが認知されるだけでおれとしては十分といえます.

dm-writeboostの最大のネックは, 個人が開発していることです. 今まで開発されてきたキャッシングソフトウェアはすべて, 企業のサポートがついています. 単なるアプリやツールではなく, ストレージソフトウェアという非常にコアなソフトウェアでは, 企業がサポートしていることは大きなメリットになります. 個人と企業で決定的に違うのは, テストの量です. 個人では, マシンリソースもないですし, 時間もないので, 出来るだけ本体のコードをシンプルで美しい形にして, テストが少なくても大丈夫という状態に持っていくことを狙います. なぜならば, 問題を洗い出せない可能性が高いからです. 企業では, お金をかけてテストが出来ますから, 直せるかどうかは別問題として, 問題は洗い出せる可能性が高いです.

だから, しっかりと考えられたテストスイートを開発して, 公開することには大きな価値があるのです.

あとは, dm-writeboostの開発自体はあまりやることがなくなったので, ともすると死んだプロジェクトと思われる可能性があります. そこで, テストスイートを作っていれば, アクティブであって, 品質を高めようとしているポーズは見せることが出来ます. 個人ソフトウェアのもう1つの弱点は, 「開発者がいつ失踪するか分からない」ということ(優秀な人間は好奇心が旺盛なので移り気でもある)なので, ポーズを見せ続けることにも意味があるのです.