真 もわ爛漫

しゃーら、しゃーらしゃーら

ユニットテスト

モックがねぇと生きていけないよママンみたいな時代でありまして、DIを当たり前にこなせる同僚でありがたいです。ただまぁ5年前とかDIってそんな一般的だったっけとか思いつつ今はDIって言わずとも分かる人が多いんだと思います。大昔、野良のプロジェクトの中にテスト走らせたら本物のデータベースが更新されるテストも見たことがありますがどういうことだってばよ

気づくとカバレッジは気になってなくていいのかなぁとか。一番重要なのはパーセンテージじゃなくて走ったことで、以前自分で書いたテストフレームワークが常にtrueを返すというメタなバグを経験して以降、必ず一回はわざとテストを失敗させてから書くというなます吹きになってしまいました。あのメタなバグは数千行の1行のtrue false間違いによるassertなんちゃらのハンドリングみすなのでカバレッジでは捉えられませんが、しかしやはりカバレッジが高いというのは魅惑にも見えます。

関数型知らない人が何か吠えてたときに「お前はテストを書けないのだろうな」とか書きたかったのですが黙ってました。しかし関数型ってのはとてもとても静的であることが多くて、モックがささらないときが悲劇なんですよね。Javaですら「なんだこのリフレクション」とか「なんだこのプロキシ」みたいなことがあって萎えます。Pythonだと「なんだこの死ぬほどたくさんあるオプショナル引数は」になるのですが、ソッチの方がまだマシかも。リフレクション渡すテストほど背中が痒くなることはあまりありません……C書いてないからね最近!

系の硬さとテストのしやすさとテストの意味は結構関連していて、それと対応してそれを使うプログラマの格式ばり具合とセンスのバランスも分かってくることがあります。Pythonはアホがテスト書くとアホな事態になることからひっくり返ってテスト書きやすいんですよ。Javaは中庸ですが上記のリフレクションやプロキシ的なのがたまに本当にウザイ。ほかは知らない。

最近は「あん?値で渡せよ馬鹿」な時代なので必須テストしやすい世界ですね。ツールの進化は目覚しいです

追記: guiceというのがあるそうですよ。ちなみに大企業だとどのようなツールを使ってDIをするのかは自分では決めなかったりすることが多いので、特に私なんかこういうツールには案外疎いんですのよ