テストステ論

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

(writeboost report) DMのための新しいテストフレームワークを作りたい

ライトブーストは広まりすぎた. もはや私が「飽きたので辞めます」ということは全く許されないし, 「バグがあることは分かってるけど修正出来ません」も概ね許されない.

そこでこれである. 正直にいって, よくわからない. 再現はしているということなので, 直せるとは思うが, 場合によっては長い戦いとなる. 修正しなければ開発者人生を絶たれてしまう.

2.2.0: corruption with cryptdisk on top of writeboost · Issue #111 · akiradeveloper/dm-writeboost · GitHub

ライトブーストのテストは, device-mapper-test-suite (dmts)をforkして使っている. これはフレームワークだ. デバイスを作ったりそこにIOを流したりといったことをする. この上に, フル実行すると2時間くらいはかかるテストを書いて回帰テストとしている. もしdmtsがなかったら, きっとシェルスクリプトの山が出来上がっていたことだろうが, 無論, ゴミだ.

dmtsは概ね良く出来ている. 開発者のジョーは本物のプログラマだ. しかし, そろそろ限界が近い.

dmtsはRubyで書かれている. これがまず悪い. 変数が何を表しているのかわからない. それはデバイス名なのか?フルパスなのか?それともデバイスクラスのインスタンスなのか?型がないとコードが正しいのか間違ってるのかわからない.
あと具体的に, スタックしにくいという問題がある. 例えば, dm-flakeyを作った障害注入テストが書きにくい. 「デバイスがEIOを返した時の振る舞い」はどうなってるのかとよく聞かれるので, 自動テストを見せて納得してもらえるようになりたい. スタッキングという概念を設計上軽んじてることが問題だ.
他にも, テスト内で使うデバイスは必ずlinearデバイスで包まれてしまうから, 精密なパフォーマンステストが書けない. ラッピングをバイパスする仕組みがほしい.

直近では, cryptsetupをするスタックをきれいに書けない. ドミトリの再現テストをdmtsに書こうと思ったらきれいに書けないことが分かった.

他にも色々と書きたいテストはあるし, テストが書きやすくないとライトブーストのテストは増えていかないだろうから, 今やるしかないと思う. バグも, 3日以内に直さないと殺されるということではないから, じっくり腰を据えて今後に投資するのはある. それに, dmtsがやばいということはジョーも気づいてるだろうから, まともなものを作って提案すればこっちを使うように切り替わる可能性もある. そうすれば貢献として大きい.

言語はScalaを考えている. 設計をする.