イネムリネズミ日記

_ Purely testing

Type-driven testing in Haskell (Simon Peyton Jones)より。

Simon の主張はいつもすばらしいのだけど、この発表に関しては Summary に首をかしげる人もいるかもしれない(わたしもその一人):

1. Over the next 10 years, the software battleground will be the control of effects
2. To succeed, we must shift programming perspective from imperative-by-default to functional-by-default
3. A concrete example: testing
   • Functional programs are far easier to test
   • A functional language is a fantastic test generation tool

Simon Peyton Jones, "Purely testing", 2008 スライド 2 枚目より抜粋

うむ。ほとんどの点には同意する。私が現時点で Simon と違う意見を持っているのは次の点:

• 手続き型プログラミング言語 ( C など) を使う場面は、今後もおそらく続く ( LISP マシンは普及しなかった)
• fantastic test generation tools は関数型言語以外の言語で書けないのか？書けるだろ。

実際、 Simon が褒めている Haskell の QuickCheck (a fantastic test generation tool) は、 Ruby にすんなり移植できた。もちろん、 Ruby は純粋でないので、Ruby でのテストは純粋でないが、「純粋」であることが重要だとは思わない。Haskell だって IO みたいな「純粋もどき」を使ったプログラムをテストしたいときに「純粋な」テストは意味をなさない。

私のもうひとつの個人的な意見は、「テスト対象のプログラミング言語には、fantastic test generation tools があるべき」というものである。あ、ここで勘違いしてほしくないんだけど、"fantastic" については Simon と同じ感覚を持っています。従来のテストライブラリ(UnitTest, Test Coverage, あらゆるテストの視覚化(表とか), 下流 CASE ツール)は、fantastic じゃない。現場の人ならわかってると思うけど、致命的なバグ、見付からないでしょ？そんなツール使ってもさ。

どんなプログラミング言語で書かれたプログラムも、Haskell でテストできるのは間違いない。しかし、そいつは次のような弱点を持つ:

1. Haskell や Haskell FFI を使う方法の弱点：型が合うとは限らない、bridge をうまく作れない、Haskell がとろいせいで microsecond 割込みみたいなバグは見つけられない
2. Haskell で対象プログラムをモデル化する方法の弱点：モデルが現実の実装を模倣しているとは限らない、見付かった反例が本当のバグとは限らない

Simon のスライド 43 ページには、「John が 2 番目のやり方でうまくいってるぜ」って言ってるけど、ほんとかなあ。や、John はスーパーハカーな上に頭がすんばらしく良いので、何か秘密があるのかもしらんけど。こいつについては、John に個人的に聞いてみる。

さて、これら以外にも Haskell でテストする方法があるのかもしれない。でも、僕の仮説「テストライブラリに『純粋』は必ずしも必要ない」ことが正しいなら、テスト対象のプログラミング言語で書かれた fantastic test generation tools が必要とされているはずだ。

具体例を挙げよう。Web application や、GUI 。みなさん、テスト書いてますか。テストってなんですか。テストにかかる時間、ものすごくかかりませんか。いちいち httpd とか database とか、たくさんのボタンのついた window をひとつひとつのテストの度に生成して、テストしてんの？

スーパーマリオクラブの従業員の皆様には本当に頭が下がるばかりです。時給 1,000 円ですか...

そういう事態を改善したくて Ruby でプロトタイプ実装してみたわけだけど、反応はほとんどなかった。Ruby はやっぱりそういうコミュニティなんだ...某氏曰く、「Ruby 使う人は Random Testing について知らないんじゃないですか」そう、LLer は指を加えて待ってる。便利なフレームワーク、便利なツール、便利な何か、そういうのを誰かが作ってくれるのを待ってる。どのように作るのか、何が欲しいのか、そういうのを考えているのは一握りのメンバーだけ。他の奴らは IT なんとかとか、はてななんとかで取り上げられて初めて飛びつくんだ。で、君達はプログラマなんですか、あっそう。

これは僕の失敗だ。ニーズのあるところにシーズを撒かなければならない。リサーチ不足でした。すみません。俺の時間は無駄に過ぎたが、十分いい勉強になった。さようなら。

じゃあどういうコミュニティは Random Testing について興味を持ってくれるんですかね。と自問したのだが、マイナーな言語で何かこさえてもマイナーなだけさね。 Java は Ruby とほとんど同じテクニックで実装できる(むしろ記述が長くなる分面倒だ)から、僕自身つまんない。Python に行っちゃおうかなーとも思うがそれはなんて Zed Shaw (Python の PeckCheck 0.1の実装がサイテーというのは John と話した)。となると、今、思いつく候補は C か JavaScript か Flex3 か(世間知らず)。

わーった。 C にしちゃる。ちょっとしたアイデアがあるので、うまくいく可能性がある。もっとも難問はいくつもある：ポインタ、型キャスト、void、union、致命的エラー (bus error, stack overflow, etc) を拾えない、など。うげえ、全てを救うのは無理っぽい。挑戦しがいのある課題。ともかく "a lightweight tool for random testing of imperative programming languages" が僕には必要だ。今ならまだ引き返せるので、深みに嵌まる前によーくあっためとかないと、まーた二の舞である…

ちなみに、Simon は Haskell 以外では Erlang, F#, Ocaml, Scala, Scheme, C# あたりが今後クルんじゃないの、と言っている。そうだろうね。でも、あいにく、へそ曲がりなので。そいつらに fantastic な機能を付け加えるのは誰でもできるんだよ。