ぺぷしのーげん

アプリケーションエンジニアによる雑記ブログ

なぜテストコードを書くとコードの再利用性が上がるのか?

f:id:hazakurakeita:20150902220743j:plain

きちんとした設計を行わなくてもユニットテストを書くだけでソフトウェアアーキテクチャは良い状態を保てるという話があります。そんなこと本当なのか?と思ってましたが、あるときテストコードを書いていて「あー正しいかも」と思うようになりました。今回はそのことについて書いてみます。

 

そんなこと言ってるのは誰だ

レガシーコード改善ガイドに書いてあります。

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

  • 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
  • 出版社/メーカー: 翔泳社
  • 発売日: 2009/07/14
  • メディア: 大型本
  • 購入: 45人 クリック: 673回
  • この商品を含むブログ (152件) を見る
 

 この本は有名で、どんなに設計がされていたとしても、テストコードがないコードはレガシーコードだと定義しています。

 

テストコードが書けないと気づいた瞬間

ちゃんと設計して書いたコードにユニットテストを書いているとき、「あ、これじゃテスト書けない」となったことがありました。本来は実装する前にコード書かないといけないんですけどね。ここで実装いじるので、その件に関しても大切さを痛感するハメに。

    [TESTMETHOD]
    public void testCase()
    {
      var method1 = new testClass(string path);
      var method2 = new testClass(string path);
      
      method1.run();
      method2.run();
    }    

失敗したのはこんなテストです。実装ではtestClassクラスのインスタンスは1つしか作りません。しかし、これはテストですから複数のインスタンスをまず作ります。実際にはfor文で結構な数のインスタンスを作りました。それから作ったインスタンス全てのメソッドを実行すると、なんと最後のインスタンス以外は全部失敗してしまいました。

なぜこんなことが起きたのか。調べてみると、クラス内で使うパスをstaticクラスのメンバに持たせていたのです。つまり、最後に作ったtestClassインスタンスのコンストラクタに渡したstring pathで全てのインスタンスのパスが統一されてしまったのです。

 

テストコードを書くと再利用性が向上するわけ

製品であるアプリケーションではtestClassインスタンスは1つしか作られなかったため、先ほどのような不具合は今まで見つかりませんでした。インスタンスは1つしか作らないので、仕様と言ってしまうこともできるかもしれません。しかし、再利用性を考えたらどうでしょう。何の例外もスローされず、最後に作ったインスタンスのパスで全てのインスタンスが動作するなんてバグの原因にしかなりません。

ここで覚えておきたいのが、テストコードを書くと実装したモジュールが製品アプリケーションとテストプロジェクトの2つから利用されるようになるということです。2つのプロジェクトから利用されているモジュールは1つのプロジェクトからしか利用されていないモジュールよりも再利用性が高いだろうというのは誰でも想像がつくのではないでしょうか。

 

時間がなければ実装してリリースしてからテストコードを書けば良いのです。とにかくテストコードを書いてメンテナンス性と拡張性を保ったまま開発を続けていきたいですね。

 

おしまい。