テストフレームワークの話

今日、 Twitter で RSpec が使いづらい、みたいな話出てたのでなんとなく思ったこと書く。

テストコードとの付き合い

付き合いの歴史は短くて、期間だとまだ４年くらい。薄い付き合い

Railsの仕事をさせてもらったときに、RSpecを使って書いてね、ということでRuby/Railsエキスパートの方が主導で、Ruby初めてわずか、という人たちが多いプロジェクトで書き始めた。

今でも全然だろうけど、当時はほとんど機能を知らずにベタッとしたコードを書いていた。でも、支払関連の機能を作っていた（決済ではない）りして、ケースが非常に多くて一人だけテストコードのみ書く、みたいなことを１ヶ月くらいやりまくって（Modelがほとんど）、1000ケースくらい追加、とかやっていた。割と好きな感じだった。

PHPのプロジェクト初めて・・・

今は、PHPでECサイトをやっていてシステムも古かったりしてテストコードはなかった。 （一応、動かない・使われてないテストコードはあったけど試験的に作ってみた名残、みたいな感じ）

２つ目くらいの商品検索機能拡張のタスクの時に、ちょっと余裕ができたのでテストコードを書こうと思って、調べたりテストフレームワークとか実行環境を調整したりして、一部の単体テストだけ phpunit で書いてみたりした。

PHPだと、そこまで環境整っていなかったり（環境が古いのもあると思うけど）言語仕様が Ruby よりも融通が聞かなかったりしてテストを書くのが難しい。

純粋関数を書いて、それをテストするだけならもちろん書くのは難しくなくて phpunit で十分気持ちよく書ける。それは多分他の言語でも同じなんじゃないかと。でも、副作用のあることをやろうとすると、例えば Mock/Stub を使わないと、というケースではPHPだとほぼ無理になって、Stubみたいなのは限定的に使えるのあるけど、実用には耐えない感じだった。

ので、Model（DAO）とかはテストコード書けなくて（DB周りの仕組みをテストFWがやってくれない、というものかなり大きいけど）、なるべく純粋関数を作るようにしてそこに仕様を詰め込んでテストコードを書くようにしている。

テストコード導入のうまく行かなさ具合

テストコード推進、というのを自分のチームでも少し言ってるけど、「なぜ？」という辺りをうまく伝えられてない感じでイマイチ。テストコードを書ける状況、というのも経験が無いと分からなくてやたら時間かかって・・・、みたいな感じになるので軽い推奨しかしていない。

テストコード書くにはセンスいると思うし、どうやったらいい感じで書けるのか？というのは経験でわかってくる感じがするのでもうちょっと進捗に余裕が無いとな・・・、みたいなのも。。

もうちょっと自分がコード書いてる分量が多いといいけど、営業とか提案っぽいのやらそれら用のプロト作ってる、みたいなのが多いのでイマイチテストコードを書くタイミング無い。

そんな感じなのでテストコードを人前で語るにはちょっと・・・というのはあるけど。。

RSpecが・・・、という話の背景にありそうなこと

年に１回ずつくらい、RSpecが良いとか悪いとかみたいな雰囲気の話が出てる。

前回は確か、 minitest でいいじゃん。RSpec とか書くの辛いよね、という感じだったような。

今回は RSpec 書き方わからないな、というツイートからみんな「辛いよね」みたいな話をしてる印象。

あんまり好きじゃない、という人が発言するのが多くて目立つ気もするけど、不満を感じてなかったり便利で好きだ、と思ってる人も相当多いと思うのであんまり過敏に反応する必要もないんだろうけど。

このへんの話が増えたり声が大きくなってる感じする背景はこんな感じじゃないだろか・・。

並行して複数言語を触る人が増えてそう

色々な学習コストが下がってる、多様化が進んでるとかで、複数の言語を習得していたり並行して利用する人が増えている。

テストコード書くのがRuby以外でも「当たり前」になってきてる

環境によって違うと思うけど、Rubyほどテストコード書く文化が浸透してる言語も無い気がする。でも他の言語もテストFWが整ったりテストコード必要、という考えの人が増えて来てテストコードを書く量が増えてそう。

他の言語では RSpec ほどリッチな（エコシステムが枯れてる）テストFWが無い

使う人が増えて発展・淘汰が起きてるけど、RSpecほど使い込まれているFWはまだ他の言語には無い感じ？ RSpec を使ったことがある人が増える一方で、他の言語にも RSpec の便利さを取り込みたい、というのでテストFWが増えたりして。

RSpec は学習コスト高いので、Railsみたいにガッツリ使う見込みなければ覚えるの辛い

で、同じのを作るといいのか？というと、多言語での開発が増えると一つの言語／テストFWの習得に時間を掛けるのが難しくなってくるので、「使い始めのコストが小さめに」ということが重視されたりして、RSpec の使いやすくて学習コストの小さいところだけが port された。

Rails の場合、よくも悪くもそれ自体が大きくて学習コストも高いので、RSpec も利用する量が比例して増えることになって、学習コストが高くても必要だからやる、ということになりそう。

昔なら、ある程度一つの言語で一定期間やっていく、みたいになってたと思うので良かったんだろうけど。。

RSpec がいいのか？他のテストフレームワークがいいのか？

もちろん、答えみたいなのは無いけど、RSpec が作った文化や機能が他のテストFWに取り込まれていくというのは大きいと思うので、その時点で良いものなんだ、ということかと思う。

でも、今はいろんな言語で同じことを実現できるようになってきたり、一つのサービスを色々な言語・FW・ツールを利用して構成するので、全部になるべく「共有の方法」で対応する必要があったりコストを下げていって素早く対応する必要があって、それには assert() とかの割と共通の XUnit とかの共通の設計あたり（＋構造化とかFail内容の表現）が適当に思われる流れ、なのかと思う。

今、自分で Ruby のコード書いてテストも書こうってなると、Railsなら分からないけどRails以外だともうちょっと軽量なテストFW使うのかな、という気がする。 普段は、PHPUnit だったり今やってるのが Go だったりするし。。

とりあえず、思ったことを文章にしてみた・・・。