TL;DR
サービスの品質ではなく、エンジニアの品質を向上させるためにユニットテストは書くべき。
はじめに
日曜プログラマーのみなさん、個人開発してますか?
ポートフォリオサイト、ブログ、モバイルアプリなどを気の向くままに開発しているのではないでしょうか。
では、そのawsomeなサービスにおいて、ユニットテストは通してますか?
「完成品をブラウザから動くことは確認してるけど、、、」
「テスト回すよりも新規機能を追加したい」
「いや、そもそもバグなんて発生しないから」
いろんな背景から、こだわってユニットテストを書くことは後回しになってはいないでしょうか。
(私はわざわざ休日の貴重な時間を割いてまで、テストコードは書かない派でした)
しかし、今回個人のポートフォリオ作成において、テストコードを書いてユニットテストを実施しました。
その中で様々な学びがあったため、振り返りつつユニットテストを書くことのメリットを紹介します。
個人開発でユニットテストはサボりがち
そもそもなぜ私は今までユニットテストをはじめ、テストコードをきちんと書いてこなかったのでしょうか。
ざっくりと言えば、
「品質向上のためにテストコードを書くことが、個人開発においてはコスパの悪い活動だから」
と私は考えます。
具体的な要因としては以下の3つだと考えます。
1. Logicが少ない
個人開発で運用されるサイトにおいて、複雑な分岐や処理を含むことは少ない印象です。
また、あまりに複雑なことがしたい場合は、外部のライブラリに頼り楽をすることが個人的には多いです。
従って、自身が記述したロジックに対してテストコードを書くことで、新たに発見される問題は少ないといえます。
2. Impactが小さい
多くのユーザを抱えるサービスや公式アプリ等であれば、バグの発生はイメージダウンや信頼性の低下を招きます。また、ECサイトなどであれば、サービスが停止することで多くの機会損失が生まれます。
従って、「システムの品質」=「死守すべきもの」といっていいでしょう。
一方で、個人サイトやブログであれば、極論何か問題が起きたとしても 誰にも迷惑はかけません。
従って、基本動作に問題がないことを確認すればよく、それ以上の品質追及は誰得状態になります。
3. Memberがいない
個人開発において、試行錯誤を繰り返しながらサービスが構築され、全てのフロー制御・依存関係・例外処理は脳内デバッグされていきます。
すべての設計図は開発者の頭の中にあります。
従って、E2Eでの動作確認がクリアされている時点で、単体での品質はある程度担保されているといえるでしょう。
ユニットテストを書いた方がいい3つの理由
上記のような要因からあまりテストコードを書いてこなかった筆者ですが、今回ユニットテストをおこなうにあたり得られたメリットが以下の3つです。
1. 🤔コピペコードを真に理解する
個人開発のモチベーションとして、新しい技術を触ってみたいというのが根底にあります。
従って、コードの大半はチュートリアルやQiitaからCrtl+C,V
をすること多いです。すると、経験上あまり内容を深く理解することなく、動くものが作れてしまいます。
ここで、コピペで作り上げたキメラのようなサービスを、改めてユニットテストを書くことで理解を深めることができました。
「あれ、テストコードすらコピペしたら意味ないのでは?」
と思いますが、複雑化したコードを評価できるようなサンプルは世に落ちていないようです。
2. 🔧保守性が向上する
専門家ではないので細かいことは分かりませんが、巨大なモジュールやコンポーネントはテストパターンが分かりにくく、テストコードを記述することが難解になりました。
そこで、ユニットテストのカバレッジを上げていくためには、コンポーネントを適切に分割し、StubやMockを活用しながら単体ごとに評価してくことが求められました。
マニュアルモック
従って、ユニットテストを記述していく過程で、TestableでReadableなコードに近づくことでしょう。
3. 👨⚕️過去の自分を振り返る
テストコードを通すというのは、過去の自分を見つめなおすことと同義だと感じました。
「誰だよこんな意味不明な分岐作ったのは」
「なんで同じこと何回も書いてんだよ」
そんなストレスを自分に対して感じることで、反省点と改善点を自分の中で整理することができました。
このサイクルを自分だけで簡単に回すことができるのは、テストコードを書いたおかげだと思います。
まとめ
本来ユニットテストの目的は個々の機能における品質を担保するために行われます。
一方で、個人開発程度のサービスに対して、わざわざ汗をかいて品質を担保することは、時間のない現代人にとってコスパの悪い活動といえるでしょう。
しかし、一度書いたコードを見つめなおして、あまたを使いながらリファクタリングすることで、本来の目的である技術への理解を深めることができると思います。