ありがちなレガシーなプロジェクトにテストを作っていってます。

気がつけばコチコチになっていたプロジェクト

基盤が 10 年以上前に制作されていて、それなりに売上があったために、売上を維持することにしか意識が向いてこなかったプロジェクトがありました。

それから 10 年が過ぎ

  • リリースのたびにテスターが悲鳴を上げる
  • エンジニアは多数いるが、恐ろしく生産性が低い
  • なので新機能が届けられない

みたいな状況になっていました。

しっかりとメンテされていないレガシーな現場

そのプロジェクト特徴をあらわすと、こうです。

  • グローバル変数超便利 !
  • static 関数多数
  • 年月が経っていびつに成長したコード
  • コードレビューなにそれ ?
  • 自動テストなにそれ ?

全然関係がないと思っていたら、実は課金デバグが出ていたということが何度かあり、 副作用が恐ろしくてコードを触りたくない 、という状況です。

PHP 製で、型も適当煮付けていたりするんですよね。
よくこれ現場の人頑張ってるな、と、感心すらしますね。

とにかくバグが多く、しかも自動テストがないために、修正影響が全くわかりません。

そのために有効な対策として、UnitTest テストを導入していってます。

決まりきったテストはコンピューターに任せようぜ

人間だと必ずミスしますが、プログラムは、必ず書かれたとおりに動作をします。
この特性の違いが重要です。

例えば、経験の浅いプログラマの人に「関数返り値が期待通りになることを評価してください」というと、画面や標準出力なりに結果を出して、目視チェックをするのですが、これは大変非効率です。


たとえば、

  • テストケース A の場合の結果は AAAAA になるべき
  • テストケース B の場合の結果は BBBBB になるべき

というテストがあったとして、

AAAAA や BBBBB を目視チェックするのはコストです。

これがたとえば

AAAA や BBBB になってしまったとしても、1 文字少ないことを見分ける必要があります。

1回、2回なら良いですが、何度も繰り返し行うことは苦痛です。

また「AAAAA になるべき」「BBBBB になるべき」という、期待値を覚えていることも苦痛です。

テストパターンが増えれば、さらにそのコストが増大します。


明らかに非効率です。

非効率なのですが、多くの人が 「画面や標準出力なりに結果を出して、目視チェックをする」ということの延長で考えているのではないかと思います。

しかしながら、テストパターンとその期待値をすべてプログラムコードとして表現すれば、そして 結果が OK か NG かだけ を出力すれば、繰り返すことが用意になります。

テストを構築することで 「うまく走れる」 ようになる

テストは作成することも保守することも多大なコストががかかります。

そのコスト以上にメリットがあるため、これだけテストの必要性が説かれていますよね。

テストを構築することで

  • テストからの使用把握を可能とする
  • エラーの検知をしやすくする

などの効果が期待できます。

端的に言うと「テストがあることで安心して改修できる」のですね。

ただし、ある程度テストの頭数を揃える必要があることも認識が必要かなと思います。


かなり力技でテストをねじ込んでいってます。
「ないよりは間違いなく良い」という気持ちです。

実際のどういう手段でテストを構築しているかは、また別途書きたいなと思います。