みなさん、こんにちは！はむさんです。

さて、今回は、テストについて書こうと思いますが、みなさんは、テストは書いていますか？

テストというのは、なかなか工数も必要なので、後回しにされがちなタスクです。 個人開発であれば、よっぽどのテスト好きじゃない限り書いたりはしないでしょうし、仕事の現場でも、テストの重要性や必要性を理解しているチームや組織にいないと、これまた軽視されがちです。

しかし、このテスト実はめちゃめちゃ重要な工程なんです。

想像してみてください。もしあなたが自社サービスのオーナーだとしたら？

あなたはおそらく、長期的にそのサービス運用をしたいと考えているはずです。 3 年、5 年、10 年、あるいはもっと長期的に安定的な運用を期待するはずです。

長期間運用すると必ず訪れるのがあなたが製品の開発で使用しているライブラリの更新です。 ライブラリの更新には、Node のライブラリを使用していれば、 npm update 、Ruby であれば bundle update などで簡単に実行することができます。 でも、待ってください！これらのコマンドはライブラリのアップデートを行いますが、その後、あなたの製品が今までと同じような振る舞いをしてくれる保証はありません。

そう、「ライブラリの更新」と「製品の動作保証」の両方を担保しながら、ソフトウェアを今後も安心して使い続けられるようにしなければならないという責任をあなたは負っているのです。この責任はとても重いです。「ライブラリの更新」はコマンド一発打てば解消されます。しかし後者の「製品の動作保証」はなかなか難しいです。というのも、あなたが何年もかけてつくった製品の全ての動作を保証することは至難の技だからです。

ライブラリの更新を行った後で、ソフトウェアを動かし、目視で動作を確認する！。。。みたいなことを時間をかけて行えいいじゃん！と思った方がもし居たら、、、その発想は非常にまずいです。あなたにそんなことをやる時間は誰も与えてはくれないでしょう。現実的には不可能な選択肢となります。

じゃあ、どうするのか？

ここで、テストが登場するのです。ここでいうテストとは自動テストのことで、 工程に応じて、単体テストとか統合テスト等様々な呼び方があります。

例えば、React アプリケーション界隈 で言うと、 React Testing Library とか cypress などが有名なテスト用のライブラリになります。

これらの道具を使えば、テストをプログラムすることができます。 なので、日頃からあなたが作った製品の仕様をテストに落とし込み、そのテストが通るような製品を作る、というプロセスで製品を作り続ければ、いざ大規模なライブラリのアップデートがあった場合でも、そのアップデートの前後のテストの様子さえ監視しておけば、「製品の動作保証」をするコストを最小限にするという戦略をあなたは手に入れることができるようになります。

もし、アップデート後にテストが失敗したとしても、どこのテストが失敗したかは明らかです。 今まで行ったときのように、テストが通るようにプログラムを改修すればよいのです。

想像してみてください。

あなたが毎日使っているソフトウェアのメジャーバージョンがあがり、どうしても更新しないと行けない局面になった時、もしそれまでテストを書いてきていれば「あぁ、今まで書いてきて良かった！」とそれまで積み上げてきた行為、テストをだまって書き続けてくれた同僚に、きっと感謝するでしょう。

地味な存在ですが、あなたのビジネスに大きなインパクトを与えるのがテストなんです。