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

テストステ論

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

(dmtest report) reloadがむずい

device-mapperの特徴として, tableを入れ替えることで仮想デバイスの挙動を入れ替えることが出来るという点がある. 例えば, もともとlinearで運用していたものをいきなりwriteboostにすげ替えることも可能である.

このテストをする意味はあまりないと思うで, 別段しなくていいと思うのだが, より設計を良くするために, Tableをreloadするという概念を取り入れることを考える.

すると, 問題が生じる. 例えばlinearで動作していた仮想デバイスにwriteboostのテーブルをreloadした場合, このデバイスはwriteboostデバイス型になってしまうので, なんと型が変わっていることになる.

従って, オブジェクトをmutateするというdevice-mapperが持っている概念をそのまま持ってくると, ランタイムエラーを覚悟しなければいけないソフトウェアにデグレすることとなる. これは, 私の望むところではない.

そこそこ賢い読者は気づいたかも知れないが, このTableは, 関数である. 上の例でいえば, linearデバイスをwriteboostデバイスに変換させる関数である. スクリプト言語ではこれが自然に書けてしまうがランタイムエラーしか起こらないソフトウェアになる. はいどうぞ.

全てのRubyエンジニアはだいたい糞である

これは最新の煽りだけど, 言ってることは分かる. Rubyプログラマを成長させない. Rubyだけ書いていると, 設計についてもテストについてもいい加減な経験しか積めない. もっと品質の高いソフトウェアを作る試行錯誤をしなければ, プログラマは成長しない.

話を戻す. では, 入力は常にlinearデバイスなのだろうか?RAID0ではダメなのか?thinではダメなのか?

ここでdevice-mapperのdmsetup create tableが, 1) 何のテーブルも持たないデバイスを作る 2) そののち, テーブルをreloadするの2stepsに分解出来ることに着目する. 実際に, dmsetup createはtableがoptionalである. 何のテーブルを持たないデバイスという零元のようなものが定義されているのだ.

謎はすべて解けた. Tableは関数である. それは入力型を何のテーブルも持たないデバイスとして, 出力型をそのテーブルが表現するデバイスとする. 美しすぎる. device-mapper自体が「map」というくらいだから関数型のテイストが取り入れられられているのだが, そのテストフレームワークを型で守ろうとしても, また関数型のテイストを楽しめてしまう. device-mapperを初期設計した人物は, 実はdevice-mapperをRHに売り払って金持ちになって引退したのだが, おそらくここまですべて読み切っていたに違いない.

だから, reloadというのは, 1) 今のテーブルを破棄して零テーブルに戻る 2) 新しいtableを適用する という処理ということになる. 残る問題は, この美しい概念を取り入れるとdmtestはどうなってしまうかだ. おれは凡人だから読み切れない. 凡人はやってみるしかない.

(追記)

ファンクタじゃないか?