はじめに
第1回目の本稿は、実際にテストコードを書く前に、基本的な考え方である「なぜテストコードを書くのか？」を解説します。
対象読者
- JavaScriptの基本をある程度理解している方
- テストコードをこれから書こうと考えている方
頻繁な変化への対応
まずは、開発現場で多く行われている基本的な考え方を振り返り、テストコードがなぜ必要なのかを考えて行きたいと思います。
これまでのテストの考え方
まずは、一般的なウォータフォールモデルを例に考えてみましょう。通常ウォータフォールモデルでは、設計→実装→テストという順番で、作ったものを最後にテストします。最後にテストを行うというのは、言い換えると「品質を最後に担保する」と言えます。
また、最後にテストする場合は、通常テスト仕様書などを作成した上で必要なテストパターンを洗い出し、手動でテストを実施します。
変化への対応が求められている
スタートアップのような新しいサービス開発だけでなく、一般的なSIや受託開発も含め、変化への対応が求められるようになってきました。それは、ソフトウェア自身が複雑化している上に、どのようなサービスやシステムが良いのかという意味で、答えが出にくくなってきたという背景があります。
答えがない状態でプロダクトを作るためには、まず作ってみて、素早くリリースを行い、使ってみたユーザの反応や印象をフィードバックし、それを元に答えに近づいていく必要があります。そのような形で行うためには、多くのユーザの反応を素早くプロダクトに反映するために、頻繁な仕様変更やリリースを行います。つまり、仕様変更を行う前提で開発を行う必要がある、ということです。
そうなると、これまでの「品質を最後に担保する」考え方で開発を行うとどうなるでしょうか。ソースコードの変更があるたびに、変更した部分だけでなく、「既存の影響範囲」も含めてテストを行う必要があります。しかもそれを手動で行うとなると、影響範囲を調査し、テスト仕様書を修正し、広く手動でテストを行うという多大に時間がかかる作業を行う必要があります。
この状態で、変更したソースコードを品質が高い状態で頻繁にリリースができる、と自身を持って断言できるでしょうか。
「変化に強いコード」とは？
では、そのような「変更に強いコード」とはどのようなコードでしょうか。そこでテストコードの登場です。例えばあるプロダクトコードにはテストコードが存在し、常にテストが正常終了している状態だと仮定します。そのコードを変更する必要があった場合、どうなるでしょうか。
テストコードが正常終了している、つまり各メソッドは想定通りに動いていると言えます。そこで、その仕様を追加したりテストコード変更し、プロダクトコードを変更し、テストを通す。テストが成功していれば「変更したコードだけでなく、変更していないコードも想定通りに動いている」と言えます。そこには、影響範囲の調査も影響範囲の手動テストも行いません。安心してコードの変更ができます。つまり「変更に強いコード」とは「変更した部分以外は品質を担保できているコード」であり、エンジニアが安心感を持って修正ができるコードである、ということです。
「品質を最後に担保する」から「品質を作りこむ」へ
テストコードがある状態というのは、プロダクトコードが存在する時点で品質が担保できていると言えます。そのような状態を作るためには、コーディングを行いながら「品質を作りこむ」ことが重要です。プロダクトコードを作りながら品質のことを想定し、その品質を常に確認できるようにテストコードを書いていきます。
以前の考え方のように、まずはコーディングをしてあとでテストを行って品質を担保しようという考え方とは異なります。つまり、テストコードを書くということは、書くだけでなく、考え方の転換が必要なのです。それが、「品質を最後に担保する」から「品質を作りこむ」への考え方の変化、ということなのです。
