プログラミング 美徳の不幸

Ruby, Rails, JavaScriptなどのプログラミングまとめ、解説、備忘録。

minitestを初めて使ったけど

このブログの熱心な読者なら僕がrailsのテストを書くのを嫌ってるのを以前読んだかと思う。
いままで全くテストを書かないプロジェクト、たくさんテストを書いたプロジェクトなどいろいろやってみた末の結論は絶対にバグを出さない覚悟と経験値を持った上でテストを書かないのが最も早く、安全であるということになった。

もちろんケースバイケースでテストを書いたほうが良い場合もあった。例えば仕様書だけ渡されてある会社のサーバから定期的にこういうリクエストが来るから、それを適切にさばいてバッチ処理してほしいみたいな案件(しかもデータに不整合を起こしたらめんどくさいやつ)はがっちりテストを書いたし、そもそもブラウザで検証するのに無理があった。

また、僕が前提にしているのはスタートアップのプロジェクトで、だいたいの場合サービスを壊したときのリスクが小さく、頻繁にサービスを大規模に改造していく必要のある場合だ。あらゆるテストを否定するような狂信者ではないことに注意。


ただ、最近になってやたらテキストを生で処理しないといけないコードを書いていて(独自の文法をhtml化するみたいな)、これは厄介だ。壊したらサイト全体に影響があり、かつブラウザで判断するのにパターンの限界がある。

そういうわけでひさびさにテストを書くことにした。そして最近界隈で人気がある(というかrspec嫌いという風潮が日本でも本格的に流行り始めた、僕がこのグループの方なのは言うまでもない)minitestを使ってみた。

結論から言うとminitest最高だ。rspecはテストのプログラム自体がDSLとして可読でき、美しいコード=そのままでテスト仕様書となるかのような思想があった。ついでにいえばcucumberという、もうとっくに捨て去ったので未だに書いてる人がいるかさっぱり知らないけど、これははっきりと日本語を含む自然言語で書いたテスト仕様書がテストになっていくという、一見すばらしそうな(かつ不可能だろうという思いがこみ上げる)思想を持ったインテグレーションテストフレームワークだった。

このあたりの思想は最近は批判が増えてるがBDD(Behavior driven development, 振る舞い駆動開発)とかテストファーストという概念につながっている部分が多少はあって(いや、テストファースト批判でrspec批判するのは違うんだけど)、少なからず言いたいことはrspecがもてはやされていた時期のテストに関する諸所の思想は最近見直されているということだ。

僕も、現実問題テストはすべてエンジニアが書いて、エンジニアの中で閉じた世界になっている以上コードが読みやすければそのものがテスト仕様書風になっている必要は全くないと思う。せいぜいメソッド名がどの部分をテストしてるかとか分かればいいし、それをやりたいならDSLでなくソースのコメントでも全く同じだと思う。



話はそれたが、minitestはとにかくrspec - DSLとして最小限の機能だけで簡単だ(というか標準ライブラリの拡張みたいだけど)
expect, shouldがうんたらかんたらというそれ自体がサービス開発にはなんら貢献しないような雑務に付き合わされている方にはぜひ進めたい。