PDCで「ユニットテストの将来」というパネルディスカッションが行われた。会話のほとんどはモックに注目していた。モックフレームワークが使われすぎているというのが全体的な意見であった。
意見はこのようなものである。多くの場合、必要なインタフェースをすべて実装することはひどく単調で、時間がかかる。だから、物事を簡単にするために、人々は、モックフレームワークを使う。これは、ただ根本的な問題を隠すだけである。その問題とは、APIが複雑すぎることだ。
人気のあるテーマは、「開発者のテスト」とそれ以外の人がするテストの間の違いについてである。常にディスカッションを通して、開発者はユニットテストを書くだけだという考えがあった。要望に対するテスト、受け入れテスト、統合テスト、そして他の形式のテスト全ては、誰か他の人の問題である。
これは、ユニットテストのコミュニティの基本的な誤解をはっきりと示している。具体的に言うと、全ての開発者が、他のタイプのテストをすべて扱うQAチームを持つという前提を持っているのだ。残念ながら、数百万ドルの会社でさえ、QAリソースがまったくないことが多く、すべてのテストは開発者とエンドユーザに残されている。
さらに多くのタイプのテストをサポートしない第一の理由は、スピードである。ユニットテストはすでに遅すぎて、ネットワークコミュニケーションを含むさらに遅いテストをする余地はない。不運なことは、他の選択肢が考慮されなかったことである。
例えば、ユニットテストフレームワークは、もっとスマートになり得るはずだ。そのフレームワークによって、実際に変更したコードのテストを再実行するだけのためにコードカバレッジの結果を使うことができる。１つのクラスを変更したために、テストスイート全体を再実行する必要はない。「ユニットテスト」という言葉そのものが、小さなサブセットをテストできることを表している。
議論されていない他の可能性は、分散プログラミングを活用することである。コードとテストは、複数のサーバに素早くアップロードして、サーバ間で実行できる。私たちは、継続的統合で行われた作業から必要な技術を全てすでに持っているのだ。
セッションの初めに、データベースが軽視されていることが認められた。大抵のデータベース開発者は、ほんの少しか、または、まったくユニットテストの考えを持たず、彼らをサポートするツールも少ししかない。もっと問題なのは、交渉の場に参加するように聞かれもしないことである。残念なことに、彼らについて言われたのはそれがすべてであった。
パネルで、社会的な問題を正す実際の選択肢はどこにも示されなかった。
肯定的な面としては、モデリングツールを使ってユニットテストを簡単にすることについて議論がなされたことである。規約レベルで始めるような多くの選択肢がここにある。規約は、実際のテストを書くコードジェネレータによって使われるだろう。明らかに、100%の解決策ではないが、共通のシナリオのために痛みを減らすだろう。
別の有望な考えは、デルタ状態を管理するものである。大抵の人々は、テストの口座は100ドルで始まり、取引の後で80ドルになると仮定する。代案は、最初に現時点のバランスを読み、それから20ドル減ったかどうかを確認する。この方法で、テストを走らせる度に、テスト環境をすべてリセットする必要がなくなるのだ。