ちゃんとテスト書いてますか?

こんにちわ、モバイルソリューション事業部でサーバーサイドを担当してるアキです
暖くなってきたとともに花粉の季節の到来ですが、いかがおすごしでしょうか。

弊社では週1で持ちまわりで部署の垣根なくエンジニアで集まって技術発表をしております。
今日は先日自分が発表した内容をせっかくなのでブログにも書きたいと思います。


いつも笑いを取ることに力を入れすぎる余り、要約すると内容がないよう。となりますが、沢山しゃべってもこういう場では伝わりきらないので良しとすることにします。良しとしてください。


Q.ちゃんとテスト書いてますか?


そんなタイトルでやりました。


テスト大事なのは当然なんですが、ちゃんと見ればいろんな方法がありますよね。できればフル活用したいですよね。とはいえ、テストって辛い時がありますが、僕だけですか?きっとみんなそうなので、一緒に頑張りましょう!というお話です。


LinterとFormatter


このスライドの一枚を思いついてしまったがタメに今回の題材を決めたといっても過言ではないです。


スクリーンショット 2018-03-09 15.00.41.png

が、ジェネレーションギャップなのか、全く笑いがおこらなかったのでツライばっかりでした……。


テストコード書いたり、テスト回したりする前にもっとLinterとFormatter活用しましょうよ。というお話。

個人的にJS界隈でのフォーマッタPrettierが良い感じで、さらにES-Lintとの組み合わせが強力で素敵だと思います。ちなみにRubyにもRufoというフォーマッタがありますがイマイチ人気があがってこないですね。でもLinterはRubocopを使わないほうが少ないんじゃないでしょうか。その連携が上手くいくと良いですよね。


エディタでリアルタイムでLintするほか、Pre-commitでフックすると効果的です。Node.js系であればいろいろありますが、一つの例としてhusky + lint-staged、Rubyであればpre-commitというGemがありますので導入も簡単です。Pre-commit時だとキツい場合はPre-pushでも良いかと思います。

要点は、バグを混入させないように自動で防げるものはやったらいいよね、という話。


スクリーンショット 2018-03-09 15.00.58.png

もう1点、僕が考える運用として「ルールは聖域とする」ことです。WARNINGなどは警告のみで無視できるものも多いです。ただし、無視できるルールを無視してると割れ窓理論的にどんどんルールが無視されていって、結局Lintしてる意味がなくなってきてしまいます。無視していいルールなら、そもそもルール自体の制約を緩めるべきで、検出されたら直しましょう、という意味での「ルールは聖域」です。理想論的な部分もありますが。


ビジュアルリグレッションテスト


視覚的回帰テストですね。そこまでメジャーじゃないものの、BackstopJSなんかは導入が以前より遥かに楽になっててびっくりしました。デザインの変更は意図した変更と意図しないものがあるので、最終的には人の目の判断ですが、それでも転ばぬ先の杖としてかなり有用ですね。


ちなみにコードレベルではなく、見た目レベルでの差分を出すため、例えば同じサイズだけど画像が差し変わってしまった場合なんかも検知できます。モバイルソリューション事業部のサーバーサイドではあまり出番はないですが、使えて損はないですね。


デモをしたんですが、だいぶ私的なものをサンプルに使ってしまったのでここでは残念ながらお見せできません。


ユニットテスト


テストと言えばユニットテストなので、今回はアサーションに絞ったお話です。Rubyのテストツール、Rspecが与えた影響は素晴しいと思います。テストコードがかなり英語と同じ感覚で読めるので、何を意図しているかわかりやすいです。その反面、デフォルトで使ってる限りは、テストに失敗した時に、何が失敗してるかが掴みにくいこともあります。またマッチャが多いため、複雑になってくると相応に学習コストも上がっていきます。


スクリーンショット 2018-03-09 15.01.47.png

個人的にはテストで詰まった時がツライので、Rspecのような自然言語寄りの思想より、Power-assertを好んでいます。Power-assertの場合、テストをパスしなかった場合の情報がわかりやすく表示されるので何を修正すべきか判断しやすいです。また、マッチャもシンプルなままなのも良いですね。その反面、実装や仕様を把握してないとテストコードからテストの意図を読み取るのはRpec的な自然言語に近いほうが良いかもしれませんね。


スクリーンショット 2018-03-09 15.01.57.png

余談ですが、RspecでPower-assertを使う方法もあります。


ここもやはりデモをしたんですが、だいぶ私的なものをサンプルに使ってしまったのでまたしても残念ながらお見せできません。


E2Eテスト


Rubyでは既にデファクトスタンダードとなったCapybaraがありますが、今回はササっとサンプルを作ったのでNode.js系のNightwatchでデモをしました。思ったより簡単に書けました。フレームワークやドライバーはたくさんあって書き方も変わりますが、一つ使えると応用が効く範囲ですね。


また、最近特にヘッドレスブラウザの活躍が目覚しいので、CI上で回せる点も良いですね。なお最近ではコーディングなしでテストが作れるような流れもあるので、もはやエンジニアではなくディレクターさんがテストを作ってしまう、ということも可能になりそうな気配です。ここはササっと紹介だけになっちゃいました。



まとめ


いつも業務のテストではRspecばかりですが、今回ビジュアルリグレッションテストを使ってみたり、JESTを触ってみたりしていろいろと知見が増えました。JEST、良いですね。相性もありますがPower-Assertとも組み合わせられますし。ビジュアルレグレッションテストは導入も簡単なので上手く使っていきたいですね。


テストの書き方に困ることはありますが、「どんなテストも無いよりマシ」を胸に、なるべくテストを沢山書いて、安心して開発していきたいと思います。

この記事へのコメント