その昔、プロジェクトの単体テストを自動化してみようと思い立ち、色々やったときの困ったところとやったことをまとめてみました。
その１
一つのクラスや関数が巨大
パターンを網羅するテストを書こうとしても、クラスのインスタンスを生成するのが困難だったり、１個の関数の分岐点が多すぎてテストパターンが膨大になる。テストを作るのに大量のモックやスタブが必要になって工数がかかりすぎた。
対策
保守で参加したプロジェクトが巨大なレガシーコードでテストできない。これが一番自動化を断念する理由になるんじゃないかな？
この場合、無理して全部テストしようとするより、自分の書いた部分だけはテストで保護しようと努力しました。どうしても依存が激しくて無理！って場合は、その部分を関数化したりラッパークラスを作ったりして、モックやスタブを使えるようにして回避してました。レガシーコード改善ガイドって本を読むとイメージ付くかも！
その２
時間が無い
開発工数が少ないのでそんな時間はない！
単体テストの時間が短い！
対策
最初はテスト自体を書くのに時間がかかってしまったけど、慣れてくると「手動で確認」の工数と「コードを書いて自動化」の工数はそんなにかわらないところまできました。
コードいじるたびにテスト用にデータ作ったりコード弄ったりしてた時間が無くなって、時間が短縮されていったのかなと思います。
その３
何をテストしたらいいかわからない
最初は仕様を確認するテストを単体テストとして書いてましたが、仕様確認を単体テストとしてしまうと、認識違いや設計変更でプロダクトコードをちょっと修正すると、テストコードの修正量が膨大になっていく。
対策
仕様の確認は結合テスト。単体テストでは自分の書いたコードが「想定通り動くか」をテストします。最初はコードを書いたら、そこを通るテストを書くって意識でやるといいかも。その時に必ずカバレッジレポートを出すと、テストしたところが緑になっていって幸せな気持ちになれます 
自動化したことによる変化
レガシーコードからテスト自動化の単体テストで保護した結果、以下の効果がありました。
コードが綺麗になる
１つのメソッドにズラズラと処理を書きなぐるタイプの人も、テストがめんどくさくなるので小さく細かく作るようになるので、とてもコードが見やすくなった。
結合テスト以降でシステムエラーの発生が皆無になった
レガシーコード時代はテスト中に思わぬシステムエラーが発生したりしていたが、自動化後はこれが無くなったので、仕様に対して集中してテストすることができた。
※後に結合テストも自動化しました。
動作確認が容易になる
お客様から問い合わせなどあった時の動作確認で、以前だとテスト環境にユーザーデータや関連データをimportして、必要なマスターデータを作って云々・・・と準備が手間でしたが、自動化後はモデルをダミーデータとしてインスタンス化できるので、動作確認用のスクリプトをがすぐ準備できて、実行することができました。
まとめ
ある程度のプロジェクトで個人で始めても、どうしても続けるのが難しいです。
特にそれを仕事中でやるとなると、難易度がプロダクトコードによって変わってしまうので、チーム全員でやるべきかなと思います。
結局のところチーム全員で取り組めたのが一番の成功の要因かなと思います。
ちなみにこの時は、チーム全員がテストコードを書くようになるまで、約２年程くらいかかりました！
自動化してみよう！って時は周りに声をかけて根気強くやりましょう。