はじめに

こんにちは！Unit～E2Eのテスト自動化を生業にしている、いしいと申します。

ユニットテストに限らず、何かを始めようと思ったとき、人は様々な壁に直面しますよね。知識・経験の問題、コストの問題（金銭、時間）、メンタルの問題（納得感、不安感）、それらが複合的に結びつく社内政治的な問題などなど・・・。そして、それらの壁を乗り越えて第一歩を踏み出すことには大変な困難を伴います。

この記事では、ユニットテストを書いていくのにあたって、どのような壁・問題があるのかを確認し、それに対してどのようにアプローチをすれば乗り越えられるのかを考えていこうと思います。

ユニットテストの壁とその乗り越え方

メンタルの問題

根本的にモチベーションが上がらない

それはユニットテストのメリットや魅力に理解、納得がいっていないからです。人間、無駄なことをやりたいとはなかなか思えません。仮に、無駄と思いながらやったとしても、大抵本質的なところを見逃しているので、価値のないアウトプットしか出てこなかったりします。ということで、無理にやる必要も、無理にモチベーションを上げる必要もありません。最初にやるべきことはユニットテストのメリット・魅力を知り、納得すること！まずは焦らず、ユニットテストのことを知ってあげましょう！

モチベーションはあるけど、色々理由をつけて逃げてしまう

趣味で実装するならともかく、仕事で実装する場合は使える時間が限られています。そのうえ、ユニットテストがなくてもプロダクトは動くし、手動で動作確認するなどの簡便で分かりやすい代替手段まであります。この状況で、知識のない分野に手を出すリスクをとれる人がどれだけいるでしょうか？そうそういないですよね。（反語）なので、ユニットテストをやったことがない人が仕事で急にユニットテストをやれと言われても出来ないのは当然です。ユニットテストは作った本人がやるのが原則と言われていますが、最初期の導入に限って言えばそれは嘘です。ユニットテストをわかる人にサンプルを作ってもらう、ユニットテスト専属のエンジニアを一人立てて先駆者として道を切り開いてもらう、…そういった戦略を立ててとりくんでいきましょう！「少しのことにも、先達はあらまほしき事なり」というやつです。（違うか？）

コストの問題

そもそもユニットテストを書く時間が見積もられていない

ユニットテストはなんだかんだ書くのに結構時間がかかります。（そのうえメンテナンス負荷も侮れない…）きちんと書く場合は、最低でも書かない場合の2倍は見積って欲しいです。

とはいえ、そこまでの時間を確保するのはなかなか難しいですよね。そういう時は、ユニットテスト専門の人を立てて、その人だけは集中的に頑張れるように工数を工面するとか、全体的に少し多めに見積もって、最初はメリットの享受を諦め、メンタルの問題を解消するまで練習期間を設ける、本当に大事なわずかな箇所だけユニットテストを実装する、などすると良いかと思います。それすら難しいという場合は、根本的にユニットテストのメリットへの納得感がまだ足りていないか、あるいはプロジェクトの現状に限りなくミスマッチなのだと思います。ユニットテストはあらゆるシチュエーションで万能に機能する銀の弾丸ではありません。プロジェクトの動向を観察し、「やっぱり必要だな」と思った段階で導入するのも選択肢の一つです。ただし、ユニットテスト未経験者ばかり集まっている場合は「今から始めます！」と言って始められるものではありません。準備期間も必要だという点には十分ご注意ください。

知識・経験の問題

ユニットテストのメリデメをきちんと理解できておらず、期待が高すぎる

「とりあえず理想的な実装でやればメリット得られるでしょ！ホワイトボックスで実施して、カバレッジはC2（条件網羅）を100％！TDDでやるぜ！」…無茶です。

ユニットテストと言えばTDD！といった印象がありますが、TDDはあくまで開発技法です。TDDをやっていなかったとしても、リファクタリング時の心理的安全性の確保、リグレッションテストの高速化といったテストとしての価値はあります。無理してTDDに拘って開発者に心理的不安感を与えることにメリットは全くありません。拘わりすぎるのはやめましょう。とはいえ、TDD（BDD、ATDD）には設計をより深く考えさせるという捨てがたいメリットもあります。挑戦できるならばぜひ挑戦してみましょう。TDDに限らないですが、始めるコツは完ぺきにこだわらないことです。メソッドの規模や重要度は気にせず、まずは分っている要件をちょろっと書き出して、それをNGからOKに変えるところから始めることです。

ホワイトボックスやカバレッジにこだわるのもやめましょう。拘わり過ぎると手段と目的が入れ替わってしまうからです。大事な機能や動作をきちっとテスト（ブラックボックステスト）したら、あとのカバレッジはただの指標です。なぜカバレッジが大きく上がったのか（実装漏れがあるかも？）、下がったのか（全然検証していないところあるかも？）を振り返るための目安でしかありません。100％だから良い、80％だから良い、ではなく、どう変化して、それは何故なのか？を大事にしましょう！

手はつけてみたけど、普通にわからん。なんか違う気がする。効果が出ない

手をつけられた時点であなたは素晴らしいです！！一番大きな壁を乗り越えたといっても過言ではないでしょう。

ただ残念ながら、ユニットテストはあらゆるソースコードをテスト出来るわけではありません。テストしやすいもの、しにくいもの。テストしてもあまり意味のないものもあれば、テストしにくいけど重要だからテストすべきものもあります。あまり深いことを考え始めると手が止まってしまうので、まずはできるところからやってみましょう。ユニットテストの実装になれてきたな、書くことに抵抗感がなくなってきたな、と思えるようになったら、ステップアップしましょう。

たとえば、アジャイルなどでイテレーティブな開発を行っている場合は、その後の手動テストで検知された不具合を見て、どこをテストしたら良かったのか振り返ってみる、そしてその個所について実装する、などの積み重ねをしていってみるとよいでしょう。

テストのための技がそもそも分からないという場合は「レガシーコード改善ガイド」などの書籍をあたってみるのもいいですし、インターネットでスタブや、オーバーライド、メソッドの切り出しなどで検索するとそれなりに情報も出てくると思います。

あるいは、テスト技法や後続のテストとの住み分けといったテストそのものに対する知識・経験が足りていない場合もあるかもしれません。もしQAチームが案件にいる場合はペアプロ的に単体テストをやってみると良いでしょう。いない場合はチームから何人か（チームの規模によりますが）QA専属のメンバーとして働いてもらってペアプロするのも良いと思います。この時、たとえ知識レベルに差があったとしても、双方が敬意を持ち、対等な関係になるように注意をしてください。（とても大事）

なお、フロントエンドのユニットテストはユニットテストという名のほぼ結合テストです。事前準備的な処理が結構あり大変です。もしバックエンドより先にフロントエンドに挑戦しようとしているならば、それはおそらく死出の旅になります。初めての挑戦としては難しすぎるので、まずはバックエンドから挑戦しましょう。

おわりに

今回の記事ではあまり体系的にユニットテストの魅力については書きませんでしたので、ひょっとすると「そんなに苦労してまでユニットテストやる必要なくない？」と思われた方もいらっしゃるかもしれません。たしかに、ユニットテストの実装にはここまでに書いたように多くの壁が存在します。

必要なものだけを上げても、まずユニットテストができるだけの適切なコーディング力、テストフレームワークの理解といったユニットテスト特有の開発知見が必要です。チームが置かれた状況に応じた適切なテスト戦略、テスト設計の知見といった完全にテスト寄りの知見も必要です。また、それらを行うだけの時間・計画と、それらをやり遂げられるという自信も必要になってきます。

ですが、それらの壁を乗り越えた時に得られるメリットもまた計り知れないものです。

・不具合の早期検知
・システム改修時の機能保証、それによる心理的安全性の確保
・ユニットテスト設計の副次的効果による実装の再考（レビュー）機会の獲得
・ユニットテスト実装の副次的効果によるテスタブル（複雑でなく、再利用　性が高い）なソースの実装
・テストレポート出力による仕様や実装状況の可視化

などなど、得られるメリットは膨大です。

幸い、テストコードはソースを上手くテスト出来ないことはあっても、ソースを壊すことはありません。（リファクタリングとか始めなければですが）恐れず、面倒くさがらず、是非ともチャレンジしてみていただけると嬉しく思います。

長い文章をお読みいただきありがとうございました。 　

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/